[Fontconfig] matching multiple families in <alias> and <test> (was: Lucida Sans/Grande/Unicode matching confusion)

[Raimund Steger]

Akira TAGOH wrote:
> On Wed, May 2, 2012 at 12:52 AM, Raimund Steger<rs at mytum.de>  wrote:
>> [...]
>> I think that most users, when they use multiple families in the upper part
>> of<alias>, think of something like:
>>
>>   "Now if I use<accept>, then append after the last occuring
>>    value out of the ones I just specified"
>>
>> and
>>
>>   "If I use<prefer>, then prepend before the first occuring
>>    value out of the ones I specified"
>
> Hmm, if people really expects to do so, having separate rules behaves
> differently then.

That's true, it would be a different behavior. Hm, now I'm not so sure 
anymore. (Many users probably don't really realize that they deal with a 
list of families they compare with, not just one.)

>> I. e. maybe something like having FcConfigMatchValueList() return first
>> _and_ last match in the actual value list and use the latter for append
>> edits.
>
> What if there are<family>  lines more than two?

It would, given this example config:

   <alias>
     <family>Family1</family>
     <family>Family2</family>
     <family>Family3</family>
     <family>Family4</family>
     <family>Family5</family>
     <accept><family>AppendedFamily1</family>
             <family>AppendedFamily2</family></accept>
     <prefer><family>PrependedFamily1</family>
             <family>PrependedFamily2</family></prefer>
   </alias>

and this query:

   FC_DEBUG=1 fc-match Family0,Family1,Family6,Family4,Family3,Family7

result in this after substitution:

   [...]
    family: "Family0"(s) "PrependedFamily1"(w) "PrependedFamily2"(w) 
"Family1"(s) "Family6"(s) "Family4"(s) "Family3"(s) "AppendedFamily1"(w) 
"AppendedFamily2"(w) "Family7"(s) "Bitstream Vera Sans"(w) "DejaVu 
Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus 
Sans L"(w)
   [...]

i. e. prepend/append occurs around the leftmost/rightmost actually 
matching family of the list that was specified in the original pattern.

I just started changing fccfg.c to test it, when I noticed that if some 
rather standard/fallback family occurs in a test, append edits would 
always be applied after its last occurence which will be pretty close to 
the end of the whole list, possibly also not what users expect. So maybe 
the idea with using the binding isn't so bad :-)

> Anyway, I think we may have some options so far:
>
> 1. Drop FcOpComma and warns it's not supported syntax.
>
> 2. add an attribute to<edit>  and<alias>  to let fontconfig know where
> to edit. e.g. pos="first|last|binding|all"
>
> 3. keep current behavior
>
> there may be more though. but I don't think taking option 3 is a good

What I can also think of (at least for <alias>), is to not use 
FcOpComma, but create as many FcTest objects (and add all of them with 
FcConfigAddEdit) in FcParseAlias as there are families in the upper part 
of <alias>, thus simulating what a user would do creating separate rules 
for all of them.

Raimund