The TrueType font format (and probably others) permits family and style names to be provided in multiple languages (using several national encodings). I've wanted to include a mechanism for making these available to applications for a long time, in fact this remains the only release blocking feature for fontconfig 2.3. I've got a couple of mediocre ideas and am searching for more; if we can't manage to figure out something sensible, I suggest that we just ship fontconfig 2.3 without this feature soon. I've had this idea that we must always provide a Latin encoded name for every font, which immediately requires support for multiple names for the same font. Today, I'm wondering if it wouldn't just be easier to provide a single name for each font and select that name in some straightforward fashion from the list of available names. I see the identification of the 'native' name for the font as a requirement in any case, perhaps we should simply make 'native' == 'sole' and be done with it. In any case, the questions here are whether we require Latin names and whether we support multiple names for each font. If we do permit multiple names for fonts, we need to identify how those names are reflected through the Fontconfig API. One possibility is to identify one name as the 'canonical' name which represents the sole element of the FC_FAMILY/FC_STYLE pattern element and to place the additional names in another pattern element. This would permit 'smart' applications to discover these additional names for presentation purposes while not bothering 'dumb' applications. However, this would also make font matching problematic -- it would be tricky for applications to figure out how to match fonts against non-canonical names, and that seems wrong. Another possibility is to provide all of the names in the FC_FAMILY pattern element. Order the list so that the 'preferred' name occurs first and even na?ve applications will end up presenting fonts in the right language. Listing would return all names and it would be up to the application to sort through them to find the desired presentation. This would require some parallel property marking the language(s) for each name. Fonts with a single name would not need this additional property. A third possibility is to present each font multiple times, once for each supported language. A tag in the pattern would mark the languages for each entry so that listing would be able to filter out names appropriately. The biggest issue here is the elimination of duplicate names by somehow identifying the entries cooresponding to the same font. I think the combination of file name and font index should suffice, but it would place a significant burden on applications to perform this elision manually. If anyone else has another alternative, I'd love to hear it. At present, I'm leaning towards either the 'only one name' solution or the 'all names in one font'. The 'only one name' solution would be significantly easier to implement and deploy, but seems less friendly to the user. -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/8c3fe871/attachment.pgp
