Bug 82582

<match target="font"> 
    <test name="family" compare="contains"> 
      <or> 
        <string>MYingHeiB5HK</string> 
        <string>MYingHeiGB18030</string> 
        <string>MSung GB18030</string> 
        <string>MSung B5HK</string> 
      </or> 
    </test> 
    <edit ....... </edit>
</match>

The above doesn't give any warning. Nor did it affect other fonts (that are not listed in <test>) but <edit> is not applied to the fonts listed in <test>. 

Replacing the nested <test> as shown below works but I got a warning that 'test does not have a name'. 

<test>
    <or>
      <test name=...>
      <test name=...>
    </or>


The old form (that worked in 2.7.x) still works even though I got a warning about 'multiple values in test'. 

I also tried the old expression with 'qual="any"' added. It works as intended (that is, for any of the 4 fonts listed, <edit> is applied), but gave me the same warning about 'multiple values in test'. 

   <test name="family" compare="contains" qual="any">
        <string>MYingHeiB5HK</string>
        <string>MYingHeiGB18030</string>
        <string>MSung GB18030</string>
        <string>MSung B5HK</string>
    </test>

> Replacing the nested <test> as shown below works but I got a warning 
> that 'test does not have a name'. 

I was wrong about the following form. This one does not work properly because <edit>'s are applied not only to the 4 fonts listed but also to other fonts as well. 

<test>
    <or>
      <test name=...>
      <test name=...>
    </or>

So, at the moment, the only way that works for me is an old expression (2.7.x expression) even though it emits a scary warning message.

(In reply to comment #0)
> I *think* the correct way to write it is:
> 
>  <match target="font"> 
>     <test name="family" compare="contains"> 
>       <or> 
>         <string>MYingHeiB5HK</string> 
>         <string>MYingHeiGB18030</string> 
>         <string>MSung GB18030</string> 
>         <string>MSung B5HK</string> 
>       </or> 
>     </test> 

That doesn't even work. the required value types to test depends on the value of the "name". at the above example, string, and sometimes integer, boolean etc. but <or> always returns a boolean. so that fails.
I think too it is the way to go sensuously though, then the kind of the boolean operators may needs to be fixed to work as <test> similarly. the current implementation for them is really useless.

> I hear in the past (with 2.7.x), this used to work:
> 
> <match target="font">
>    <test name="family" compare="contains">
>         <string>MYingHeiB5HK</string>
>         <string>MYingHeiGB18030</string>
>         <string>MSung GB18030</string>
>         <string>MSung B5HK</string>
>     </test>
>     <!-- Turn on light auto-hint -->
>     <!-- Turn off sub-pixel anti-aliasing -->
>     <edit name="hinting" mode="assign"><bool>true</bool></edit>
>     <edit name="autohint" mode="assign"><bool>true</bool></edit>
>     <edit name="hintstyle" mode="assign"><const>hintslight</const></edit>
>     <edit name="antialias" mode="assign"><bool>true</bool></edit>
>     <edit name="rgba" mode="assign"><const>none</const></edit>
>  </match>
> 
> but with 2.11.x started warning about multiple strings in <test>...

See Bug#33644.

I see...

I think we should update the DTD to allow <or> around tests, not the other way around...  Lets think a bit more about it though.

In the meantime, http://lists.freedesktop.org/archives/fontconfig/2014-August/005298.html has two ways to achieve what I want to do.

I assume that this issue is still outstanding in the latest release.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/65.