Around 10 o'clock on Oct 16, Lars Knoll wrote: > The problem I have with this approach is what happens if you at some point > also choose to offer "fantasy" CSS name (actually the user could do it by > editing his own fonts.conf). That would require the user to patch and > recompile Qt to get it in the font list. I guess we could codify the 'standard' generic names somehow so that this cannot happen. Alternatively, we could add a configuration parameter and API to list these generic names. That way people could add new 'generic' names and applications would still be able to tell the difference between those names and the 'real' font names provided by FcListFont. > If possible I'd like to get both names with on FcFontList command. The reason > is that I'd like to have a mapping between international and localized name. > If I understand you correctly this would be the case with your approach. Yes, FcFontList returns patterns holding all of the information from the fonts, so it will have all of the names. One issue is that you will get multiple entries if fonts have different sets of family names. For naive applications, that will show up as multiple entries for the same family, which seems undesirable to me. I'm not quite sure how FcFontList could solve this problem. > I'd guess that most fonts have at most two family names. An international and > a localized one. In this case, the approach using RFC 3066 language tags is > maybe overkill. It would suffice to get them both side by side with an easy > API. RFC 3066 language tags have the advantage of already being present in the fontconfig API and providing a nice notion of territory and language. These very same tags are used in HTML and the C locale mechanism; this should reduce the amount of code needed in applications as they won't have to translate to yet another weird naming scheme for languages. Inside fontconfig, the only cost will be a small table mapping the TrueType language tags to RFC 3066 values. That table should be quite small. -keith
