Around 10 o'clock on Oct 26, Ambrose Li wrote: > Firstly, from the viewpoint of a (traditional) Chinese speaker, > "supporting Big5" is indistinguishable from "supporting > traditional Chinese" That was the assumption I made in using the Han coverage from Big5 as the basis for the zh-tw orthography, similarly, I used GB18030 for zh-cn coverage and JIS for ja coverage. As you say though, there are an awful lot of glyphs in that encoding which are so rarely used that a font without them could still be usefully used for essentially all documents. > And not all traditional Chinese fonts support the bulk of Big5; decorative > fonts may support only the "frequently used characters", i.e., the first > 5401/13051 = 41% of the original Big5 space, a lot of these aren't even Han > characters; I believe this would make fontconfig conclude that such fonts > do not support Chinese. Insomuch as they can't really be used to correctly display nearly all documents, this statement is true. Much as many decorative Latin fonts include only upper case, you wouldn't want one of them picked to present messages to the user. > This is probably ultimately more philosophical than practical, > unless an app plainly refuses to work with a font when > fontconfig tells it that a language is not supported. Mozilla > used to be such an app, but it seems to have somewhat improved > in this regard. The current design of fontconfig places the application (and indirectly the user) requested family name at the highest priority -- if an application requests 'Bitstream Vera Serif' while running in a zh-tw locale, it will get 'Bitstream Vera Serif' and not have it's choice overridden to a font which supports zh-tw. Mozilla may still limit the fall-back font choices in it's dialogs to those which do support the specified language, but it will not override document specified families. -keith
