On Mon, 2004-11-29 at 12:52 -0800, Keith Packard wrote: > 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. There are plenty of scripts used by many different languages. What's the native name for a Arabic font with Persian, Urdu, and Arabic names? It probably depends on who created the font... What about a font that spans multiple scripts? > > 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. Doesn't strike me as unlikely that someone creating a font would start off with a Latin name and only later figure out how to add additional names. Other than CJK fonts, most of the fonts we ship with RHEL/Fedora don't have localized names at all. If people start adding them, should things break? > > 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. I think that's an elusive concept. > > 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. Hmm, I thought I remembered David Turner doing work to give FreeType reasonable ASCII font name selection. > > 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. My plan for Pango is to only reveal localized names with a specialized function like pango_font_face_get_display_name(). And maybe magically make them work if used in font descriptions. Reordering based on locale seems like making things hard for everybody. > > > 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. That's a very slim idea of "compatibility". A user is going to be considerably more confused by seeing a font twice, as compared to seeing it once with a Latin name, I expect. The former is introducing new weirdness. The former is just leaving current limited functionality in place. Regards, Owen -------------- 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/ee14e44e/attachment-0001.pgp
