Around 12 o'clock on Nov 29, Phil Race wrote: > If the names are used to populate a font menu for example, then > its important that there's some way to select the name that's > most appropriate for the user's locale. (the following is intentionally contentiously dialectic to try and find the best solution) This is surely the case for fonts used to display text in that locale, but I'm not sure as convincing a case can be made for fonts used to display text for other locales. In fact, I would be unsurprised if multi-lingual users would prefer to see each font name presented in the appropriate language; that would certainly make it easier to select useful fonts. Relevant here is the fact that the bulk of the fonts I've seen with multiple language names is that they simply add an English name alongside the existing "real" name, presumably so that English-only UIs (like Fontconfig today) can present something to the user. It could be argued that supporting multiple names is unnecessary in this environment; English users are unlikely to want to use these fonts for presenting English text, steering them away by presenting the names so that they can't read them might actually be considered a feature. Is it not useful to discourage non-Chinese speakers from using the Arphic fonts? > I have come across fonts that have ONLY a Chinese name, > so its impossible to insist on the Latin name being the name. > If the font doesn't have a Latin name, I don't know a good solution. > I suppose you could use the postscript name but that's not really > the right thing from the perspective of the Chinese user. If the postscript name is the only one available in the font, then that's what fontconfig will use today. I agree that we should figure out how to identify the 'native' name of the font and try and present that most of the time. This, however, contradicts your suggestion above that we try to present names in the current locale... > We'd end up having to resolve these to file names to see that they were the > same font, and even then I'm not at all sure what we'd do when its a TTC > file. Fontconfig includes both a file name and an 'index' into the font to identify elements of TTC files, so at least it would be possible (if painful) to identify shared fonts. > So I think providing 'all the names in one font' is the most useful. > Without that I know we'd not be able to use fontconfig for font > enumeration. We'd have to continue to parse the fonts ourselves > to extract that information. Ok, so the question remains as to whether we should continue to also present the non-native names for the font (assuming we can correctly identify the native names for all fonts). > [[Although so long as only family names are listed, then we need > to do that to extract the full face names too, ie add FC_FACENAME > or similar.]] I'd like to know why the full face names are interesting given the availability of the family and style names. Is there additional information missing here from (some, many, all) fonts? This does point out that we really need to convert the cache file format to something mmap'able so that all applications can share the same pages for this data. That's a post-2.3 activity though; I'd really like to finish up this release if we can find a good solution to the localized name issue... -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://freedesktop.org/pipermail/fontconfig/attachments/20041129/0a7c2512/attachment.pgp
