ÔÚ2004Äê11ÔÂ30ÈÕµÄ06:12£¬Keith PackardдµÀ£º > Around 16 o'clock on Nov 29, Owen Taylor wrote: > > > There are plenty of scripts used by many different languages. What's > > the native name for a Arabic font with Persian, Urdu, and Arabic > > names? It probably depends on who created the font... > > I guess I'm wondering if there really are fonts with multiple localized > names, or if fonts appear as I've found them with one real name and an > English transliteration as used for the the Postscript name. In other > words, is this an actual problem? Or just a theoretical limitation. I > have no fonts which run counter to my model at present. > > > What about a font that spans multiple scripts? > > Right now, I've got several such fonts and all provide only an English > name. > > > Doesn't strike me as unlikely that someone creating a font would start > > off with a Latin name and only later figure out how to add additional > > names. Other than CJK fonts, most of the fonts we ship with RHEL/Fedora > > don't have localized names at all. > > This does seem more likely; as systems begin to support localized names, I > agree that font designers are encouraged to provide them. I think this > point, and the related issue of changes in Fontconfig breaking > configurations are pretty compelling. > > > Hmm, I thought I remembered David Turner doing work to give FreeType > > reasonable ASCII font name selection. > > Perhaps this was after Fontconfig had already adopted its current mechanism > for locating ASCII names. I do know I found many fonts presented through > FreeType without suitable names a few years ago. > > > My plan for Pango is to only reveal localized names with a specialized > > function like pango_font_face_get_display_name(). And maybe magically > > make them work if used in font descriptions. > > I don't know what 'localized names' means in this context any longer. If > we agree that font matching must use all of the names, and font listing > must provide all of the names, then we really just have a list of names > (and a cooresponding list of languages). > > The only priviledged name in this list is the first value in the pattern > element; existing applications will end up preferring that in presentations > to the user. I suggest that we place the name we want users to see here, > we just need to decide whether that's English or the "preferred" name found > in the font itself. I submit that always using English would be a poor > choice, and that we instead let font files direct which presentation to > use. Systems like Pango could then walk the list of available names and > select based on locale or whatever (a simple convenience function that > matched a locale/lang could be included in fontconfig). With the simple convenience function, it would be pretty convenient for high-level application to present 'preferred' name/list to end user. but i am curious how we can implement it in fontconfig. In my understanding, Given one locale/lang, besides the lang set, the other information that fontconfig can rely on to decide the 'preferred' name/list is the CodePageRange data in OS/2 table. it would works well for CJK font as the bit 18-20 will be always set in CJK TT font to address UniHan issue, but not sure for other fonts. Maybe you can use the platform id/encoding id if the font isn't Unicode based, but you still have to use iconv API to convert their 'preferred' name to UTF8. Just for reference. Currently the workaround that can be made in Pango is: check the value beyond 0 in the FC_FAMILY element if fontconfig can put those native name into the element by fixing in fcfreetype.c, if it exists, with the current lang tag, check whether the font contains the tag in its lang set with FcLangSetHasLang, if yes, present its native name to gtk font selection dialog. but its limitation is: it doesn't work for some font that contains so much scripts, as a result, family name in korean would be presented in either 'de' or 'fr' locale because the korean font contains all 'de' and 'fr' characters. The desired sceranis is that we present APPROPRIATE and MEANINGFUL name to *END USER*, i.e chinese name in chinese locale. if my understanding is correct, we wouldn't expect germeny user will like korean name, right? As for matching function, given either lation or native name, fontconfig already matchs well with current implementation, i mean 'provide all of names in the FC_FAMILY pattern element, don't understand why there exists any back-compatibility issue. Anyway, thanks a lot for your effort, Lars said 'it seems to be pretty important feature for them', actually IT IS. -federic > > That's a very slim idea of "compatibility". A user is going to be > > considerably more confused by seeing a font twice, as compared to > > seeing it once with a Latin name, I expect. The former is introducing > > new weirdness. The former is just leaving current limited functionality > > in place. > > Well, I guess the best plan is then to try the one-font/multiple-names > approach and see what breaks. Transcoding the font names from the weird > set of encodings used in TrueType files appears likely to be the largest > part of the code; I think the remaining bits are relatively simple. > > There is the issue of where to store the associated language information. > I think I can just stick it in a separate element that parallels the > family and style names. > > -keith > > > > ______________________________________________________________________ > _______________________________________________ > fontconfig mailing list > fontconfig@xxxxxxxxxxxxxxx > http://freedesktop.org/mailman/listinfo/fontconfig
