OK, some (belated) comments here; after thinking it over for a few
days, I'll admit to still having reservations about your
scheme. From the least important:
- The OS/2 language code page tags are really crufty; about
the only reason that they are OK is that we aren't interested
in anything beyond FC_LANG_JAPANESE, FC_LANG_SIMPLIFIED_CHINESE,
FC_LANG_TRADITIONAL_CHINESE, FC_LANG_KOREAN_WANSUNG (?).
Even for these, it seems necessary to reinterpret the original
meanings for something like a GB18030 font.
- Limiting the set of languages for which we set FC_LANG has
another benefit; it reduces unexpected side effects from
setting FC_LANG.
However, it does mean that there are needs for language-specific
handling that aren't covered. For example, say I have two
fonts:
A) Covers western european languages
B) Covers Hebrew + ASCII
In a Hebrew locale, if you want matched ASCII and Hebrew
for "Sans" you are going to have a problem, since no
language-specific handling is done.
Some language-specific configuration is clearly outside
of the scope of fontconfig; for instance, bigger default
fonts are needed for CJK. Does this mean we can ignore
the fact that "Sans" won't be right (in this hypothetical
example) for Hebrew?
Can we assume that people will simply have fonts big
enough to cover all character sets that need to be
typographically matched? (Hebrew/ASCII is marginal.
Latin/Greek/Cyrillic need to be coordinated.)
- The current fontconfig CVS has a simple rule:
Any families in the pattern explicitely are more
important than language tags.
Any families that come from the fonts.conf file are
less important than language tags.
I like the simplicity! The fontconfig machinery
definitely is skirting the line of "too hard for users
and most programmers to understand" already.
I'm not sure that the effects will be what people
expect, for example:
Specify:
Sans,SomeRandomArabicFont
Expected:
The character from "Sans" if the font contains it,
otherwise the character from SomeRandomArabicFont
Actual:
The character from SomeRandomArabicFont if the font
contains it, otherwise the character from "Sans".
In fact, I think the above is incompatible with the
intent of CSS2 matching. As another example:
In your config file:
<match target="pattern">
<test qual="any" name="family">
<string>helvetica</string>
</test>
<edit name="family" mode="assign">
<string>arial</string>
</edit>
</match>
Specify:
Helvetica,Nimbus Sans L
Expected:
Get Arial
Actual:
Get Nimbus Sans L
The second problem is easy enough to fix by extending
the fonts.conf syntax to allow:
<edit name="family" mode="assign" binding="strong">
<string>arial</string>
</edit>
(Probably with "strong" the default). The first problem seems
rather intractible; I don't see how to fix it and retain
a flat list.
One idea:
What would ditching a flat list look like? Well, the "cheating"
way to do it and keep FC_FAMILY a list of strings would be
to go the magic string route
"Arial", "Sans", Helvetica
"Arial", "@Nimbus Sans L,Verdana,Kochi Gothic", Helvetica
(or whatever) I doubt doing string parsing when matching would
be a significant cost.
The idea is that matching any element the list would be more significant
than FC_LANG, but the position in the list would be less
significant than matching FC_LANG.
Implementing this would do some violence to FcCompareValueList,
but it would be localized violence, I think.
To support per-user aliases, I think you would need to expand
<edit> a bit. Probably something like
<edit mode="group_append"><string>Kochi Gothic</string></edit>
Which turns "Sans" into "@Sans,Kochi Gothic"
A "non-cheating" approach of making FC_FAMILY not hold strings
is probably a) too incompatible b) too complex, considering
that the programmer never needs to worry about the sub-lists.
I don't like this method much; too magic, too complex.
Another idea:
Make groups (aliases) first class entities. Semantics are basically
the same as the above, but fonts.conf includes:
<group>
<family>serif</family>
<prefer>
<family>Times New Roman</family>
<family>Nimbus Roman No9 L</family>
<family>Luxi Serif</family>
<family>Times</family>
</prefer>
<group>
This defines the group "serif" if not already present and prepends
the given families to it. (Matching can be done with only one
hash table lookup per input FC_FAMILY pattern element to
FcConfigSubstitute with a little bit of trickiness.)
The main thing I don't like about this is that it gets confusing
to have both <alias> which does pattern subsitution and <group>
that defines a group. Maybe it would be possible to get rid
of <alias><prefer> and <alias><accept> and rename
<alias><default> to something else?
OK, this mail is too long already; I guess the one sentence
summary is: your mechanism gives me most of the capabilities
I need but doesn't give the semantics I would expect.
Regards,
Owen
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
