First, a description of the problem, then some proposed solutions.
The problem:
1) An application wants a simplified chinese font and prefers
AR PL SuntiL GB, so it builds a font pattern:
AR PL SungTiL GB,serif:lang=simplifiedchinese
2) Fontconfig grubs through the configuration database and finds
the alias for 'serif' which expands this pattern to:
AR PL SungTiL GB,Times New Roman,Nimbus Roman No9 L,Luxi Serif,
Times,Kochi Mincho,AR PL SungtiL GB,Baekmuk Batang,serif:
lang=simplifiedchinese:
(along with the other usual defaults)
3) AR PL SungTiL GB isn't installed, and Fontconfig gives precedence
to family name matches over lang matches, so this pattern matches
'Times New Roman'. That's bad; 'Times New Roman' isn't know for
it's ability to present simplified chinese text.
The obvious fix here is to make 'lang' bind tighter than family name,
and in fact, fontconfig used to do just that. However, now an application
which asks explicitly for 'Times New Roman:lang=simplifiedchinese' will
never get Times New Roman unless no simplified chinese fonts are installed.
That's also bad.
Clearly, family names substituted in for the 'serif' generic name should
somehow bind less tightly than the language group, and the language group
should somehow bind less tightly than family names explicitly specified by
the application.
I have two possible solutions:
a) Move the 'generic' aliases to a new pattern element using:
<match target="pattern">
<test qual="any" name="family">
<string>serif</string>
</test>
<edit name="generic" mode="append">
<string>Times New Roman</string>
<string>Nimbus Roman No9 L</string>
<string>Luxi Serif</string>
<string>Times</string>
<string>Kochi Mincho</string>
<string>AR PL SungtiL GB</string>
<string>Baekmuk Batang</string>
</edit>
</match>
Now make "generic" come after "lang" in the match rules and
have it match the "family" member of the font.
(obviously some syntactic sugar would help here)
b) Mark the generic names as "fallbacks". Any substitutions
relative to these marked names would also get marked.
Now change the matching rules to bind 'lang' in between
fallback and non-fallback family names.
I think these two notions are functionally equivalent, interposing 'lang'
between the application-specified and generic-substition family names.
The first is easier to implement, but requires every font configuration
file to change (a minor flag day) or continue to get the wrong fonts. It
also codifies in some sense the current matching mechanism, something
I'm not sure is right.
It is nice that the current matching mechanism is relatively easy to
explain, and I suspect having something this simple will keep users and
applications from being too surprised, so perhaps piggybacking this
solution on top of something users can probably understand is a good thing.
However, the second solution has the advantage of keeping all of the
family names together during the match, and making the global fonts.conf
file control which family names are considered "generic". It also
keeps the underlying matching mechanism opaque, which has it's points
considering that I'm not sure it can ever quite match CSS2 in it's current
incarnation.
Keith Packard XFree86 Core Team HP Cambridge Research Lab
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
