[Fontconfig] Problem when <alias> is followed by more than one <family>

[Akira TAGOH]

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
>> https://bugs.freedesktop.org/show_bug.cgi?id=33644#c2
>
> 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.


-- 
Akira TAGOH