Re: matching multiple families in <alias> and <test>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 18, 2012 at 8:33 AM, Raimund Steger <rs@xxxxxxxx> wrote:
>  <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.

Aha. interesting. though I have no idea what one actually expects on that rule.

> Everything else, like new boolean ops or user-defined edit positions,
> although sounding neat, is just making things complicated.

agreed.

> 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.

Yes, that sounds good to me. it may be a good idea to explain that as
the examples in the document, to avoid this kind of confusion.

> 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.

Okay, I think warning it may works enough so far. it could be still
possible to have different behavior for <alias> anytime, because it
will be done in the parser and those are different.

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

Thanks,
-- 
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig



[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux