On Fri, Jul 11, 2003 at 01:54:56PM -0700, Keith Packard wrote: > The font supports all of the langs requested by the > application. I think this means that the font 'contains' > all of the langs requested by the application (remember, > we're talking about LISTING here). Now, the tricky part of > defining what 'support' means for a specific lang entry. When > the application provides a language/territory pair, then the > font must either provide a matching language/territory pair, > or a bare language entry. When the application provides > a bare language, the font must either provide a matching > bare language entry or a language/territory pair with *any* > territory: > > application font "supports" > ----------- ---- ---------- > zh zh_cn YES > zh_tw zh_cn NO This is theoretically sound. However, for practical purposes it is wrong; fonts having incomplete coverages are generally still useful (not in general but for particular tasks like typesetting short pieces or even longer pieces of text). Especially with the scarcity of free CJK fonts, it is almost a must to, for example, use zh_CN or even ja/ko fonts for zh_TW in certain cases. (The reverse is also true; i.e., a zh_TW and/or zh_CN font will be useful for setting Japanese in a limited way.) In fact, there are even commercial zh_TW fonts that cover less than half of the Big5 code space (e.g., only the "frequently used characters" space, i.e., 4501 code points out of the complete Big5 coverage of 17552; because of the structure of Big5, just having 4501 of the "most frequently used" characters should at least already make the font "support zh_TW"). With the current version of fontconfig (and gtk2), it is getting difficult to get X applications to let me use, for example, a Japanese font for traditional Chinese, even if the font is perfectly fine for the task I do, because the application will believe the fontconfig notion of "support" for my locale, and filter out all the "unsupported" fonts. I think it counter-productive to put so much trust in the mechanical notion of "complete code space coverage". Regards, -- Ambrose LI Cheuk-Wing <a.c.li@xxxxxxxx> http://ada.dhs.org/~acli/
