[Fontconfig] Heads up: Droid fonts update in Rawhide

[Raimund Steger]

Akira TAGOH wrote:
> On Thu, Jul 26, 2012 at 9:42 AM, Raimund Steger <rs at mytum.de> wrote:
>> Although I think mode="append" is smarter here, because it's an easy way of
>> retaining compatibility with all places that directly refer to the
>> locale-specific name and expect it to be enumerable with FcFontList.
>
> Ah, I got what you mean here. yes, definitely. apparently one don't
> need to have the substitution rule like:
>    <alias binding="same">
>       <family>X</family>
>       <accept><family>Y</family></accept>
>    </alias>
>
> So
>
> <match target="scan">
>    <test name="family"><string>X</string></test>
>    <edit name="family" mode="append"><string>Y</string></edit>
> </match>
>
> should be so smart in this case.
>

Yes. The main differences I see are that

(1) if family Y isn't a "real" family, or if Y doesn't support the 
'lang' in the pattern, then the <alias> rule will not return the family 
in FcFontList. The target="scan" rule will do that.

(2) if family Y *is* a real family, then the <alias> rule might cause 
its language to be ignored (at least without any additional rules) if 
someone uses FcFontMatch to ask for Y with strong binding, as that will 
override 'lang'. Conversely, if someone expects to *always* get Y 
regardless of language when asking for it, they won't be able to do it 
with the target="scan" rule. (This has the potential to cause some user 
frustration I think.)

(3) with the target="scan" rule, target="font" edits, which some people 
use to apply final twiddling to the font returned by FcFontMatch, can 
test for family Y as well.

The <alias> rule is more lightweight because it doesn't affect the 
cache, so I usually prefer that, but it's probably less of an issue for 
distribution-provided fonts.


Raimund



-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346