On Mon, 2004-11-29 at 11:29 -0800, Keith Packard wrote: > 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. I select a font in the font dialog, it's saved in my preferences, I change locale and it stops working? A web page developer lists a font in a stylesheet, and it is only selected for user's in some locales? An application uses a font name, the next release of the font adds a new translation of the font name into a local language, and the font is no longer found? I strongly believe that fonts should have a canonical "programmatic" name that is basically independent of locale. Since this isn't a feature of font formats (well, other than postscript names), we can't truly provide this. But using the ASCII/Latin name as is done currently by FreeType for the primary name of the font comes close. > 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. I see non-canonical names as being primarily a user interface element. Though I guess the question is "how do Chinese-language web pages specify fonts"; if using Chinese language family names in chinese web pages is common, then that probably argues that matching against non-canonical names is important. Dan Williams (cc'ed) mentioned something to me about Word documents specifying names in non-ascii encoding. Though OpenOffice isn't currently using fontconfig properly, that might be more evidence. > 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. Can you do this in a way that isn't going to break existing applications that use the listing APIs? While invisibly matching against non-canonical names as a fallback might be neat, backwards compatibility is vastly more important. > 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. I'd dislike this one quite a bit. Applications that want to do simple things should be able to do them simply. Plus it sounds hard to do this without causing further memory-footprint and time overhead. Regards Oen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://freedesktop.org/pipermail/fontconfig/attachments/20041129/56f0044f/attachment.pgp
