[Fontconfig] Font matching in Unicode locales

[Keith Packard]

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