[Fontconfig] matching multiple families in <alias> and <test>

[Raimund Steger]

Akira TAGOH wrote:
> On Wed, May 16, 2012 at 9:11 AM, Raimund Steger<rs at mytum.de>  wrote:
>> You mean comment #8 in that bug
>> ( https://bugs.freedesktop.org/show_bug.cgi?id=33644#c8 )? Well I think that
>> suggestion would be a different interpretation than what is currently
>> implemented.
>
> Yes. and actually it's not a suggestion but the real behavior on
> current implementation. it may works only on the limited conditions
> though.

Yeah, one could say that ;-)
For example, in the rule mentioned in that comment: --

   <test name="object" qual="all">
     <string>A</string>
     <string>B</string>
   </test>

-- I think the first value ("A") will be ignored, because only the last 
iteration of the while-loop in FcConfigMatchValueList() has the chance 
to set the return value. So the following snippet -- changed to use 
"style" to make the pattern have no fallback values with typical configs:

   <match target="pattern">
     <test name="style" qual="all">
       <string>Roman</string>
       <string>Bold</string>
     </test>
     <edit name="some_property">
       <string>some_value</string>
     </edit>
   </match>

will match (and apply "some_property") if called like this:

   FC_DEBUG=1 fc-match :style=Bold |grep some_property

but not if called like this:

   FC_DEBUG=1 fc-match :style=Roman |grep some_property

in both cases the pattern element contains a single value at the moment 
of the match, while the test contains two. Only the last value from the 
qual="all" test is effectively checked.

> [...]
> I'll think about it more though, I tend to think of getting rid of
> FcOpComma so far. if there are any use-cases that there are no
> workaround or any other reasonable suggestion, please let me know.
>

A part of me tends to agree (to remove FcOpComma syntax from <test>). 
Everything else, like new boolean ops or user-defined edit positions, 
although sounding neat, is just making things complicated.

At the moment, if users want an AND, they can write multiple <test>s. If 
they want an OR, they can write multiple <match>es. For anything more 
complex they can assign custom properties to use them later in the 
config. So basically I can't think of anything that cannot already be 
achieved.

However, there are probably a lot of existing users who have FcOpComma 
in their rules that accidentally works. So it could be trouble to switch 
that syntax off, and another part of me tends to not change anything 
(and endure future inquiries about that <alias> thing). Or maybe 
implement a warning as is also suggested in that bug.

In the end I think I'm fine with whatever solution you'll come up with...

Raimund