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). > 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 -------------- 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/93264cf7/attachment.pgp
