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

[Akira TAGOH]

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. that's why I'm a bit concerned about the inconsistency.
otherwise all of the combinations for qual's and mode's should be
documented to avoid confusion. that would helps us to remember how it
is supposed to work ;)

> Using other qual's than "any" with FcOpComma in <test> should trigger some
> pretty awkward behavior at the moment, because the order of FcOpComma
> operands will decide which one is used to check for the position(s) in the
> pattern, which is totally counter-intuitive (for example, I think for
> qual="all" the last operand would need to get the match, while for
> "first"/"not_first" it's likely different).
>
> But it's not allowed currently anyway ;-)

Hmm, I'm not sure. it may be easier to address this if we leave the
decision of where the position <edit>s would be applied on to the
users?

> You mean using <or> etc. not only to calculate ordinal FcTypeBool values,
> but also for disjunction of subexpressions in <test>?

Yes, something like that. it may be needed particularly if using qual
for that purpose is a bad idea.

> But still, as you said, the problem where to apply edits if more than one
> value matched remains...

That's true. it may be relevant each other but should be a separate issue.

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.

-- 
Akira TAGOH