[Fontconfig-bugs] [Bug 33644] Fontconfig doesn't match correctly in <test>

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33644

--- Comment #16 from Akira TAGOH <akira at tagoh.org> 2012-04-02 19:52:32 PDT ---
(In reply to comment #14)
> How about:
> 
> <match>
>   <or>
>     <test ...>...</test>
>     <test ...>...</test>
>   </or>
> </match>
> 
> ?

According to the DTD, it's not supposed to work.

(In reply to comment #15)
> This would be abusing current semantics.  Currently qual="all" means all values
> of the elements match the provided value.  You are turning it into something
> else.  I don't think we should do that.

Well, I may be misunderstanding what you are saying. assuming that "elements"
means "objects" in the pattern, because you were referring to "provided value"
there. I have no idea anything else. if my guess is wrong, sorry in advance -
That sounds inconsistent. the document says:

    if 'qual' is 'any', then the match succeeds if any value in the field
matche
s.
    if 'qual' is 'all', then the match succeeds only if all values match.
    if 'qual' is 'first', then the match succeeds only if the first value
matche
s.
    if 'qual' is 'not_first', then the match succeeds only if any value other
th
an

it doesn't talk about all values of the *elements* and other _qual_ doesn't
behave that way. given that your explanation is true, that is meaningless with
specifying 'name' in qual="all".
In fact, the target object is determined when creating the test object with
FcTestCreate(). there are no way to see what else the objects is available
after that. and actually "qual" is evaluated every time once a test unit is
done. thus qual="all" behaves the AND expression and qual="any" behaves the OR
expression in current implementation.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.