Around 10 o'clock on Nov 30, Lars Knoll wrote: > But the font might also be specified in the localized name. Windows commonly > displays fonts localized to the locale of the user. These font names will > most certainly also get used in documents, as there is no easy way to get the > latin name of the font in the API. So what happens when you move a document from a zh_CN locale to en_US? Does the system still manage to locate the right fonts? I suggest that for our purposes, we must be able to store either family name in the file and match that correctly in any locale. > They want to see the localized font name (preferably in the language of the > font, ie. a chinese font should have a chinese name). To me, 'Localized' is a technical term which means 'present according to $LANG', which isn't always the same as 'Chinese font given Chinese name'; I'd like to see the Chinese family names even in the en_US locale. In contrast, Phil Race pointed out that the Arial fonts provide multi lingual style names. I think applications should present style names in localized form if possible, so in a vi_VN locale, I would expect to see Arial as the family name and th???ng as the style name for the Arial roman face. However, I think fontconfig should present information in a locale-neutral fashion and let the UI designers decide how to present the data. Any attempts to do otherwise will probably only end up annoying application developers. > Listing fonts should probably give either the localized or the latin name > with the possibilty of retrieving the other one as well. Font matching > should try both (or all if the font has several) names, as you otherwise > will run in some trouble with documents created on Windows. Ok, I think we can do that. Listing will provide all of the family names and let you pick the one you want to present. Each name may have an associated set of locales. Matching will treat each family name identically; a name in the pattern will be tested against all of the family names found in the font. Lemme code some stuff up and see what it looks like. -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/20041130/76236aef/attachment.pgp