Bug 59438

Summary: Fix <alias> inside <match>
Product: fontconfig Reporter: Behdad Esfahbod <freedesktop>
Component: libraryAssignee: fontconfig-bugs
Status: RESOLVED FIXED QA Contact: Behdad Esfahbod <freedesktop>
Severity: normal    
Priority: medium CC: akira, freedesktop
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Behdad Esfahbod 2013-01-15 21:15:15 UTC
Currently the alias doesn't respect the tests.

Also check / fix DTD.
Comment 1 Akira TAGOH 2013-01-22 07:56:13 UTC
(In reply to comment #0)
> Currently the alias doesn't respect the tests.

I think it was fixed in 2.10.0 with http://cgit.freedesktop.org/fontconfig/commit/?id=ddefa5021f7785514f373aab6a8e6191a867278e

<alias>
        <test name="lang">
                <string>ja</string>
        </test>
        <test name="family" qual="all" compare="not_eq">
                <string>IPAGothic</string>
        </test>
        <family>sans-serif</family>
        <default><family>IPAGothic</family></default>
</alias>

$ FC_DEBUG=1028 fc-match
...
        Loading config file /home/tagoh/.config/fontconfig/conf.d/00-test-in-alias.conf
Add Subst match
        pattern any lang Equal "ja"
        pattern all family NotEqual "IPAGothic"
        pattern any family Equal(ignore blanks) "sans-serif"
edit
        Edit family AppendLast "IPAGothic";

That said, as you say fontconfig does deal with <alias> inside <match> too:

        <match>
                <alias>
                        <family>sans-serif</family>
                        <default><family>foo</family></default>
                </alias>
        </match>

$ FC_DEBUG=1028 fc-match
...
        Loading config file /home/tagoh/.config/fontconfig/conf.d/000-bz59438.conf
Add Subst match
        pattern any family Equal(ignore blanks) "sans-serif"
edit
        Edit family AppendLast "foo";

Add Subst match
edit
Comment 2 Akira TAGOH 2013-01-22 08:39:26 UTC
Proposed fix:
  http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz59438

Hmm, that just looks like one of issues because the elements are parsed by FcEndElement() when an element enclosure is being closed. I guess there should be much better approach to get all happier. that said, the code itself doesn't know what element is allowed to be the parent but DTD. I suppose libxml is capable to check it with enabling the feature.
Comment 3 Behdad Esfahbod 2013-01-23 22:56:32 UTC
Or we can make it valid to have alias in match.  Otherwise, lets just close this.  Having a way to enable DTD verification (envvar and cmdline arg to fc-* tools) in libxml is useful.
Comment 4 Akira TAGOH 2013-01-24 10:58:45 UTC
Okay, here is another proposal:
  http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz59438-2

the test case in comment#1 in question would introduces the warning in this case and no more make the empty match pattern:

$ FC_DEBUG=1028 ./fc-match/fc-match
...
Fontconfig warning: "/home/tagoh/.config/fontconfig/conf.d/000-bz59438.conf", line 7: No <test> nor <edit> elements in <match>
...
        Loading config file /home/tagoh/.config/fontconfig/conf.d/000-bz59438.conf
Add Subst match
        pattern any family Equal(ignore blanks) "sans-serif"
edit
        Edit family AppendLast "foo";
...

This doesn't prevent <alias> inside <match> exactly though.

(In reply to comment #3)
> Or we can make it valid to have alias in match.  Otherwise, lets just close
> this.  Having a way to enable DTD verification (envvar and cmdline arg to
> fc-* tools) in libxml is useful.

Sure. but I suppose that feature isn't available in expat. it may be a good opportunity to switch the default parser to libxml though, as we had Bug#34266 in bz, we need to polish a bit for libxml support perhaps. there seems some distros enabling it by default, it's not used in Fedora. so I'm not sure how better it works on. maybe I should try...
Comment 5 Akira TAGOH 2013-10-31 13:16:31 UTC
just merged a patch in comment#4 regarding Bug#71085. let me close this at this moment so that it works enough for this purpose. and may be better filing an RFE for DTD validation perhaps.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.