[Fontconfig] Problem when <alias> is followed by more than one <family>
akira at tagoh.org
Mon Jan 16 03:10:38 PST 2012
BTW please send to the list too...
On Mon, Jan 16, 2012 at 7:51 PM, lolilolicon <lolilolicon at gmail.com> wrote:
> On Mon, Jan 16, 2012 at 5:24 PM, Akira TAGOH <akira at tagoh.org> wrote:
>> I'm assuming that the document is always true to explain the behavior.
>> IMHO that would be good to discuss changing it as long as it less
>> affects for existing applications though.
> I see your comments in bug #33644 about <or> now. Indeed, people
> naturally want to do bitwise OR <test>s in <match>, and <family>s in
> <alias>, as demonstrated by the configs 30-metric-aliases.conf,
> 40-nonlatin.conf and 45-latin.conf.
Honestly I'm not quote sure how to use that... no examples nor any
cases anyone uses it in the real world. explicitly using a bitwise
element would be obvious though, it may looks too complicated.
>>> First, the configs shipped with fontconfig have <alias> followed by a
>>> bunch of <family> elements, namely 30-metric-aliases.conf,
>>> 40-nonlatin.conf and 45-latin.conf. I thought it's wrong configuration,
>>> but now I realize it's not that simple.
>> I suppose it's a bug for the config in fontconfig. please file a bug then.
> OK, I will.
>>> Second, I tested with the equivalent <match> rules:
>>> -- SNIP --
>>> and I get exactly the same results as before.
>> I'm not sure what this "before" points to, given that it doesn't work
>> as you expected as in the original mail, this is also correct behavior
>> and also documented. see also a comment in
> Very helpful, thanks. A warning should really be printed if it's invalid
> syntax, unless we make it valid syntax :)
>>> $ fc-match lolfont
>>> HelveticaLTStd-Roman.otf: "Helvetica LT Std" "Roman"
>> That may depends on the priority of the "Helbetica LT Std". though
>> these seems some bugs in fontconfig to deal with <alias>. it may be
>> one of them.
> "Helvetica LT Std" does not have any special priority in my setup, i.e. no
> other rule regarding it at all. I'm pretty sure it's a bug. Not in
> <alias>, though, because the equivalent <match> with the three <string>s
> in <test> gives the same result.
If it behaves differently after removing the line of <family> for
lolfont, that may be a side-effect of a bug of multiple <family>
elements in <test> as <alias> is a syntactic sugar for that, I guess.
More information about the Fontconfig