[Fontconfig] Font matching in Unicode locales
keithp at keithp.com
Mon Oct 27 02:42:16 EST 2003
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.
More information about the Fontconfig