Around 15 o'clock on Nov 29, Owen Taylor wrote: > I select a font in the font dialog, it's saved in my preferences, > I change locale and it stops working? No, the idea was to identify the 'native' name for each font and use that everywhere. > 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? That would be possible, but it seems unlikely that a font would suddenly sprout a 'native' name when previously it had none. I suppose this could happen is if the font was originally distributed in Type1 format and provided only a Postscript name and then was converted to TrueType and had the native name added. However, this is just as likely to result in a change in the English family name; Type1 fonts often provide only a full face name from which the family must be extracted. > 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. Yes, locale independence is an absolute requirement. But, that doesn't demand that we use the same language for every font. Identifying the 'native' name for the font would permit us to have both a canonical name and a suitable presentation for the expected target audience. > But using the ASCII/Latin name as is done currently by FreeType for > the primary name of the font comes close. FreeType doesn't really identify the ASCII/Latin names correctly. Fontconfig has to grub around in the font to try and identify a suitable candidate. And, Fontconfig currently lacks the ability to transcode names from non-Unicode encodings; dealing with localized names will require the use of iconv. > 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. Yes, I've seen this as well. A canvas of font names used on web pages might be useful here to see how prevalent the English names of these fonts are. > > Another possibility is to provide all of the names in the FC_FAMILY pattern > > element. > > Can you do this in a way that isn't going to break existing applications > that use the listing APIs? I think it's a requirement that we make it work with existing applications (unless that proves impossible). Pattern elements can contain multiple values; applications (presumably) examine only the first value in each element, so placing the 'right' name in this location should make things just work. The selection of 'right' is problematic. While it would be nice to sort these based upon current locale (or lang tag specification), I'd really like to leave things in fixed order and provide a convenience function to extract the 'appropriate' presentation name in each environment. > > A third possibility is to present each font multiple times > > 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. The appeal here is precisely to avoid the above issue of potential incompatibility. Presenting these fonts multiple times ensures compatibility with existing applications while also permitting changes in applications that would produce better results. But, if the effort for making this acceptable to users is greater than the effort for using a less compatible mechanism, then I suspect we should look elsewhere for a solution. -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/70d1fbfc/attachment.pgp
