Akira TAGOH wrote:
On Wed, May 16, 2012 at 9:11 AM, Raimund Steger<rs@xxxxxxxx> 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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
