[Fontconfig] Font matching in Unicode locales

[Keith Packard]

Around 11 o'clock on Oct 25, John Alexander Thacker wrote:

> Wouldn't the right workaround be to replace "ja" with "ja,en" instead?
> I want to make the Japanese fonts available under an English Unicode
> locale, right

One of the design limitations of fontconfig is that font information is 
immutable -- there's no way to adjust the information about fonts found in 
your system.  That makes the cached font information independent of the 
configuration, allowing it to be shared among multiple users or even 
across multiple machines with completely separate font configurations.

So, one of the things you cannot do is force fontconfig to believe that 
Kochi Mincho supports English; it's missing several characters which occur 
occasionally in English text.

What you *can* do is adjust the language tags that fontconfig will use to 
perform matching, and you can create substitution rules that make certain 
fonts take precedence over the language matching rules.

Recall that in fontconfig, matching is done based on values provided by 
the application as edited by the configuration.  There is a fixed ordered 
list of values used, mis-matching in earlier entries dominates matching in 
later entries.  The relevant part of the matching list for this discussion 
is:

	"strong" family names
	language tags
	"weak" family names

Each value in the system has either a "strong" binding or a "weak" 
binding; values provided by the application are (by default) strong while 
values provided by a substitution rule are (by default) weak.  So, any 
aliases in your configuration file add family names which will *always* 
have less influence on the overall match than the language tag values.

This mechanism was designed (or at least putatively designed) to provide
reasonable default fonts based on the language present in the document for
cases when a specified font name is either not provided or unavailable.
When Mozilla renders HTML pages with language tags, the selected fonts will
always match the language of the text, unless that text also has a specific
font tag which will override the language tag.

As a (semi) kludge, this system was amended to assume that font requests
without a specific language should probably select fonts suitable for the
current locale.  That's where you're finding adventure today.

You can "solve" your problem in two possible ways; either whack your 
default language to include Japanese or create some strong bindings to 
force font matching to prefer those fonts directly.

I added configuration entries to default the lang value to include both en 
and ja:

	<!-- set desired language if unset -->
	
	<match target="pattern">
	  <test compare="eq" name="lang" qual="all" >
	   <string>unset</string>
	  </test>
	  <edit name="lang" >
	   <string>en</string>
	   <string>ja</string>
	  </edit>
	 </match>

This makes all unspecified Han usage reference a Japanese font instead of 
a Chinese or Korean one.  The precise font used now depends on the generic 
aliases used.

The strong binding alternative would be to do something like:

	<match target="pattern">
           <test name="family">
		<string>sans-serif</string>
	   </test>
	   <edit binding="strong" mode="prepend">
		<string>Kochi Mincho</string>
	   </edit>
	</match>

(this is untested and may have errors)

This creates a "strong" alias for sans-serif that will override language 
concerns.

Please feel free to try and come up with an alternative matching scheme; 
the current mechanism is not sacred in any way, it's just the result of a 
couple of years of iterative design and obviously is still imperfect in 
many ways.

-keith