TrueType fonts have this nice feature -- they may include multiple family and style names, each with a language tag (not RFC 3066 based, but we can't have everything). It would be nice if fontconfig-based applications could display and accept these names as appropriate. Converting the TrueType language information into RFC 3066-based language tags should be relatively straightforward. In cases where there isn't a 1<->1 mapping, we can use multiple RFC 3066 tags as needed. The existing string values can be augmented in some way to tag each one. Building a reasonable API to get at the language tags may be a bit harder. One of the fontconfig design principles is the separation between font matching and font listing. Information presented to the user about available fonts is expected to come from the font listing functions, not the font matching functions. So, it seems reasonable to expect that providing some mechanism to adjust what values are returned from the listing functions should be sufficient to localize displayed font names. I suggest that a new API (FcFontListLang?) be created which accepts a list of language tags and sorts all of the strings based on that list. The existing FcFontList API would convert the current locale to a language tag and call this new function. At first blush, the font matching API needs no changes; fonts would simply have multiple family/style values and match any of them. I'd like to try this simplistic approach at first, but I'm a bit afraid that collisions between names in different languages will necessitate a more complex solution. I guess we'll see what happens. Does any of this seem horribly wrong? -keith
