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
