Fontconfig - Jan 2012 - Problem when <alias> is followed by more than one <family>

Hi, I need a little help understanding a <alias> config.

The font "Helvetica" is not installed on my system, but one called
"HelveticaNeueLT Pro 55 Roman" is; I like the later so I want to
prepend
it before "Helvetica" and "Arial".  I find that
<alias> works curiously
with more than one <family> being matched.

In ~/.fonts.conf, I have:

  <alias binding="same">
    <family>Helvetica</family>
    <family>Arial</family>
    <prefer>
      <family>HelveticaNeueLT Pro 55 Roman</family>
    </prefer>
  </alias>

then Arial is not aliased corretly:

  $ fc-match Helvetica
  HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"
  $ fc-match Arial
  arial.ttf: "Arial" "Normal"

And if I put "Arial" at first, instead:

  <alias binding="same">
    <family>Arial</family>
    <family>Helvetica</family>
    <prefer>
      <family>HelveticaNeueLT Pro 55 Roman</family>
    </prefer>
  </alias>

then Helvetica is not aliased corretly:

  $ fc-match Helvetica
  n019003l.pfb: "Nimbus Sans L" "Regular"
  $ fc-match Arial
  HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"

Here, "Nimbus Sans L" is from 30-metric-aliases.conf:

  <alias binding="same">
    <family>Helvetica</family>
    <accept>
      <family>Nimbus Sans L</family>
    </accept>
  </alias>

If I use separate <alias> for each family:

  <alias binding="same">
    <family>Helvetica</family>
    <prefer>
      <family>HelveticaNeueLT Pro 55 Roman</family>
    </prefer>
  </alias>
  <alias binding="same">
    <family>Arial</family>
    <prefer>
      <family>HelveticaNeueLT Pro 55 Roman</family>
    </prefer>
  </alias>

then the result is as expected:

  $ fc-match Helvetica
  HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"
  $ fc-match Arial
  HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"

Can you help me understand what is happening?

See the document. <alias> allows to have only one <family> and one
of
<prefer>, <accept> or <default>. the behavior is surely
following what
the document says.

On Sun, Jan 15, 2012 at 4:24 AM, lolilolicon <lolilolicon at gmail.com>
wrote:
> Hi, I need a little help understanding a <alias> config.
>
> The font "Helvetica" is not installed on my system, but one
called
> "HelveticaNeueLT Pro 55 Roman" is; I like the later so I want to
prepend
> it before "Helvetica" and "Arial". ?I find that
<alias> works curiously
> with more than one <family> being matched.
>
> In ~/.fonts.conf, I have:
>
> ?<alias binding="same">
> ? ?<family>Helvetica</family>
> ? ?<family>Arial</family>
> ? ?<prefer>
> ? ? ?<family>HelveticaNeueLT Pro 55 Roman</family>
> ? ?</prefer>
> ?</alias>
>
> then Arial is not aliased corretly:
>
> ?$ fc-match Helvetica
> ?HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"
> ?$ fc-match Arial
> ?arial.ttf: "Arial" "Normal"
>
> And if I put "Arial" at first, instead:
>
> ?<alias binding="same">
> ? ?<family>Arial</family>
> ? ?<family>Helvetica</family>
> ? ?<prefer>
> ? ? ?<family>HelveticaNeueLT Pro 55 Roman</family>
> ? ?</prefer>
> ?</alias>
>
> then Helvetica is not aliased corretly:
>
> ?$ fc-match Helvetica
> ?n019003l.pfb: "Nimbus Sans L" "Regular"
> ?$ fc-match Arial
> ?HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"
>
> Here, "Nimbus Sans L" is from 30-metric-aliases.conf:
>
> ?<alias binding="same">
> ? ?<family>Helvetica</family>
> ? ?<accept>
> ? ? ?<family>Nimbus Sans L</family>
> ? ?</accept>
> ?</alias>
>
> If I use separate <alias> for each family:
>
> ?<alias binding="same">
> ? ?<family>Helvetica</family>
> ? ?<prefer>
> ? ? ?<family>HelveticaNeueLT Pro 55 Roman</family>
> ? ?</prefer>
> ?</alias>
> ?<alias binding="same">
> ? ?<family>Arial</family>
> ? ?<prefer>
> ? ? ?<family>HelveticaNeueLT Pro 55 Roman</family>
> ? ?</prefer>
> ?</alias>
>
> then the result is as expected:
>
> ?$ fc-match Helvetica
> ?HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"
> ?$ fc-match Arial
> ?HelveticaNeueLTPro-Roman.otf: "HelveticaNeueLT Pro 55 Roman"
"55 Roman"
>
> Can you help me understand what is happening?
> _______________________________________________
> Fontconfig mailing list
> Fontconfig at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/fontconfig


-- 
Akira TAGOH

I''m assuming that the document is always true to explain the behavior.
IMHO that would be good to discuss changing it as long as it less
affects for existing applications though.

On Mon, Jan 16, 2012 at 5:48 PM, lolilolicon <lolilolicon at gmail.com>
wrote:
> On Mon, Jan 16, 2012 at 10:00 AM, Akira TAGOH <akira at tagoh.org>
wrote:
>> See the document. <alias> allows to have only one <family>
>
> Yes, that''s what I thought at first. ?But then, I find
it''s not true that
> <alias> can have only one family, with several clues:
>
> First, the configs shipped with fontconfig have <alias> followed by a
> bunch of <family> elements, namely 30-metric-aliases.conf,
> 40-nonlatin.conf and 45-latin.conf. ?I thought it''s wrong
configuration,
> but now I realize it''s not that simple.
I suppose it''s a bug for the config in fontconfig. please file a bug
then.
>
> Second, I tested with the equivalent <match> rules:
>
> ??<match>
> ? ?<test name="family">
> ? ? ?<string>Helvetica</string>
> ? ? ?<string>Arial</string>
> ? ?</test>
> ? ?<edit name="family" mode="prepend"
binding="same">
> ?? ? ?<string>HelveticaNeueLT Pro 55 Roman</string>
> ? ?</edit>
> ??</match>
>
> and I get exactly the same results as before.
I''m not sure what this "before" points to, given that it
doesn''t work
as you expected as in the original mail, this is also correct behavior
and also documented.  see also a comment in
https://bugs.freedesktop.org/show_bug.cgi?id=33644#c2
>
> Third, I''ve tested that <family> following <alias> are
all somehow taken
> into account:
>
> ?<alias binding="same">
> ? ?<family>Helvetica</family>
> ? ?<family>Arial</family>
> ? ?<family>lolfont</family>
> ? ?<prefer>
> ? ? ?<family>Helvetica LT Std</family>
> ? ?</prefer>
> ?</alias>
>
> The "lolfont" is not a real font name, and I get the result:
>
> ?$ fc-match Helvetica
> ?HelveticaLTStd-Roman.otf: "Helvetica LT Std" "Roman"
> ?$ fc-match Arial
> ?arial.ttf: "Arial" "Normal"
> ?$ fc-match lolfont
> ?HelveticaLTStd-Roman.otf: "Helvetica LT Std" "Roman"
That may depends on the priority of the "Helbetica LT Std". though
these seems some bugs in fontconfig to deal with <alias>. it may be
one of them.
>
> This makes me believe that <alias> can have one or more
<family> elements,
> and is equivalent to the corresponding <match> rules like the one
above,
> but somehow the first one following the opening <alias> or
<test> is
> treated differently from the others, i.e. order matters... ?This is where
> I''m really confused.
>
>> and one of <prefer>, <accept> or <default>. the
behavior is surely
>> following what the document says.
>
> No, the document says the <family> element can be "followed
optional
> <prefer>, <accept> and <default> elements", not
"one of" them. ?I''m
> referring to the fonts-conf(5) man page and fonts.dtd.
Sure. though it doesn''t take any effects without any of them.

-- 
Akira TAGOH

BTW please send to the list too...

On Mon, Jan 16, 2012 at 7:51 PM, lolilolicon <lolilolicon at gmail.com>
wrote:
> On Mon, Jan 16, 2012 at 5:24 PM, Akira TAGOH <akira at tagoh.org>
wrote:
>> I''m assuming that the document is always true to explain the
behavior.
>> IMHO that would be good to discuss changing it as long as it less
>> affects for existing applications though.
>
> I see your comments in bug #33644 about <or> now. ?Indeed, people
> naturally want to do bitwise OR <test>s in <match>, and
<family>s in
> <alias>, as demonstrated by the configs 30-metric-aliases.conf,
> 40-nonlatin.conf and 45-latin.conf.
Honestly I''m not quote sure how to use that... no examples nor any
cases anyone uses it in the real world. explicitly using a bitwise
element would be obvious though, it may looks too complicated.
>
>>> First, the configs shipped with fontconfig have <alias>
followed by a
>>> bunch of <family> elements, namely 30-metric-aliases.conf,
>>> 40-nonlatin.conf and 45-latin.conf. ?I thought it''s wrong
configuration,
>>> but now I realize it''s not that simple.
>>
>> I suppose it''s a bug for the config in fontconfig. please file
a bug then.
>
> OK, I will.
>
>>> Second, I tested with the equivalent <match> rules:
>>> -- SNIP --
>>> and I get exactly the same results as before.
>>
>> I''m not sure what this "before" points to, given
that it doesn''t work
>> as you expected as in the original mail, this is also correct behavior
>> and also documented. ?see also a comment in
>> https://bugs.freedesktop.org/show_bug.cgi?id=33644#c2
>
> Very helpful, thanks. ?A warning should really be printed if it''s
invalid
> syntax, unless we make it valid syntax :)
>
>>> ?$ fc-match lolfont
>>> ?HelveticaLTStd-Roman.otf: "Helvetica LT Std"
"Roman"
>>
>> That may depends on the priority of the "Helbetica LT Std".
though
>> these seems some bugs in fontconfig to deal with <alias>. it may
be
>> one of them.
>
> "Helvetica LT Std" does not have any special priority in my
setup, i.e. no
> other rule regarding it at all. ?I''m pretty sure it''s a
bug. ?Not in
> <alias>, though, because the equivalent <match> with the three
<string>s
> in <test> gives the same result.
If it behaves differently after removing the line of <family> for
lolfont, that may be a side-effect of a bug of multiple <family>
elements in <test> as <alias> is a syntactic sugar for that, I
guess.


-- 
Akira TAGOH

On Mon, Jan 16, 2012 at 7:10 PM, Akira TAGOH <akira at tagoh.org>
wrote:
> BTW please send to the list too...
Ah, sorry about that.
>> "Helvetica LT Std" does not have any special priority in my
setup, i.e. no
>> other rule regarding it at all. ?I''m pretty sure it''s
a bug. ?Not in
>> <alias>, though, because the equivalent <match> with the
three <string>s
>> in <test> gives the same result.
>
> If it behaves differently after removing the line of <family> for
> lolfont, that may be a side-effect of a bug of multiple <family>
> elements in <test> as <alias> is a syntactic sugar for that, I
guess.
Yes, removing it gives a different result, i.e. the font mapped to
sans-serif.  More than one element in <test> is the real problem here, it
behaves curiously and is quite puzzling.

Thank you, Akira.

Resending reply to list.  Sorry about the noise!


---------- Forwarded message ----------
From: lolilolicon <lolilolicon at gmail.com>
Date: Mon, Jan 16, 2012 at 4:48 PM
Subject: Re: [Fontconfig] Problem when <alias> is followed by more
than one <family>
To: Akira TAGOH <akira at tagoh.org>


On Mon, Jan 16, 2012 at 10:00 AM, Akira TAGOH <akira at tagoh.org>
wrote:
> See the document. <alias> allows to have only one <family>
Yes, that''s what I thought at first. ?But then, I find it''s
not true that
<alias> can have only one family, with several clues:

First, the configs shipped with fontconfig have <alias> followed by a
bunch of <family> elements, namely 30-metric-aliases.conf,
40-nonlatin.conf and 45-latin.conf. ?I thought it''s wrong
configuration,
but now I realize it''s not that simple.

Second, I tested with the equivalent <match> rules:

??<match>
? ?<test name="family">
? ? ?<string>Helvetica</string>
? ? ?<string>Arial</string>
? ?</test>
? ?<edit name="family" mode="prepend"
binding="same">
?? ? ?<string>HelveticaNeueLT Pro 55 Roman</string>
? ?</edit>
??</match>

and I get exactly the same results as before.

Third, I''ve tested that <family> following <alias> are all
somehow taken
into account:

?<alias binding="same">
? ?<family>Helvetica</family>
? ?<family>Arial</family>
? ?<family>lolfont</family>
? ?<prefer>
? ? ?<family>Helvetica LT Std</family>
? ?</prefer>
?</alias>

The "lolfont" is not a real font name, and I get the result:

?$ fc-match Helvetica
?HelveticaLTStd-Roman.otf: "Helvetica LT Std" "Roman"
?$ fc-match Arial
?arial.ttf: "Arial" "Normal"
?$ fc-match lolfont
?HelveticaLTStd-Roman.otf: "Helvetica LT Std" "Roman"

This makes me believe that <alias> can have one or more <family>
elements,
and is equivalent to the corresponding <match> rules like the one above,
but somehow the first one following the opening <alias> or <test> is
treated differently from the others, i.e. order matters... ?This is where
I''m really confused.
> and one of <prefer>, <accept> or <default>. the behavior
is surely
> following what the document says.
No, the document says the <family> element can be "followed optional
<prefer>, <accept> and <default> elements", not "one
of" them. ?I''m
referring to the fonts-conf(5) man page and fonts.dtd.

Hi,
> Can you help me understand what is happening?
I am really new to fontconfig, so please correct me if I am wrong 
somewhere; I am learning it and I have taken this bug as an 
oportunity to familiarize myself with it a little.

I think that the point is, that the fontconfig mechanism pick first 
<family> in the provided multiple family list in the alias, which 
exists in the family priority list yet and that is prepended 
(prefer), appended (accept) or appended_last (default).

For example, config like

        <alias binding="same">
                <family>font</family>
                <accept>
                        <family>foo</family>
                        <family>bar</family>
                </accept>
        </alias>
        <alias binding="same">
                <family>foo</family>    <!-- multiple family 
-->
                <family>bar</family>    <!-- list of an alias
-->
                <accept>
                        <family>bar1</family>
                        <family>bar2</family>
                </accept>
        </alias>
        <alias binding="same">
                <family>bar1</family>
                <prefer><family>Liberation
Mono</family></prefer>
        </alias>
        <alias binding="same">
                <family>bar2</family>
                <accept><family>Droid
Serif</family></accept>
        </alias>
        <alias binding="same">
                <family>bar</family>
               
<prefer><family>STIXGeneral</family></prefer>
        </alias>


will result (assuming all real fonts from there installed) 
into 

$ FC_DEBUG=4 fc-match font | grep family:     # shows growing family priority
list
        family: "font"(s)
        family: "font"(s) "foo"(s) "bar"(s)
   (!)  family: "font"(s) "foo"(s) "bar1"(s)
"bar2"(s) "bar"(s)
        family: "font"(s) "foo"(s) "Liberation
Mono"(s) "bar1"(s) "bar2"(s) "bar"(s)
        family: "font"(s) "foo"(s) "Liberation
Mono"(s) "bar1"(s) "bar2"(s) "Droid Serif"(s)
"bar"(s)
        family: "font"(s) "foo"(s) "Liberation
Mono"(s) "bar1"(s) "bar2"(s) "Droid Serif"(s)
"STIXGeneral"(s) "bar"(s)
        family: "font"(s) "foo"(s) "Liberation
Mono"(s) "bar1"(s) "bar2"(s) "Droid Serif"(s)
"STIXGeneral"(s) "bar"(s)
        family: "Liberation Mono"(s)
        family: "Liberation Mono"(s)

I switch order of <family>foo</family> 
and <family>bar</family> in _second_ alias to get

$ FC_DEBUG=4 fc-match font | grep family:
        family: "font"(s)
        family: "font"(s) "foo"(s) "bar"(s)
   (!)  family: "font"(s) "foo"(s) "bar"(s)
"bar1"(s) "bar2"(s)
        family: "font"(s) "foo"(s) "bar"(s)
"Liberation Mono"(s) "bar1"(s) "bar2"(s)
        family: "font"(s) "foo"(s) "bar"(s)
"Liberation Mono"(s) "bar1"(s) "bar2"(s)
"Droid Serif"(s)
        family: "font"(s) "foo"(s)
"STIXGeneral"(s) "bar"(s) "Liberation Mono"(s)
"bar1"(s) "bar2"(s) "Droid Serif"(s)
        family: "font"(s) "foo"(s)
"STIXGeneral"(s) "bar"(s) "Liberation Mono"(s)
"bar1"(s) "bar2"(s) "Droid Serif"(s)
        family: "STIXGeneral"(s)
        family: "STIXGeneral"(s)

You see from the debug output, why order of <families> in the multiple
family list in the second alias have impact on the final result.

Assuming I am right, _as_far_as_I_can_see_:
1. <default> alias isn''t affected, because when any from multiple
<families> exists in the present family priority list, default family 
is _appended_ to the end of family priority list.
2. <prefer> or <accept> alias can be wrong with more complex config
of aliased families (e. g. Arial, Helvetica *); that could be maybe
improved by changing behaviour of this multiple family list aliases: 
prepend/append _each_ family in the multiple family list in the 
alias mimicking (shorthanding)

        <alias binding="same">
                <family>foo</family>
                <accept>
                        <family>bar1</family>
                        <family>bar2</family>
                </accept>
        </alias>
        <alias binding="same">
                <family>bar</family>
                <accept>
                        <family>bar1</family>
                        <family>bar2</family>
                </accept>
        </alias>

(same with <prefer>).

@list: What should I do:
0. Forget. It can''t work this way.
1. Forget. Don''t make conf more complex. One <family> per alias
is
   perfectly ok and who believe it works with <default>, let him to 
   use it.
2. This shorthand could improve config files readability. Try 
   to check the code if you are right and if it can be implemented 
   as soon as you have time for it.


Petr


*) Enclosing log from fc-match Arial and fc-match Helvetica commands
with ~/.fonts.conf on my real system containing

  <alias binding="same">
    <family>Arial</family>
    <family>Helvetica</family>
    <prefer>
      <family>STIXGeneral</family>
    </prefer>
  </alias>

Little bit long, but you can search for "\.conf" tagged parts.
Especially interesting is of course ~/.fonts.conf.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc-match-arial.log
Type: text/x-log
Size: 94351 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120227/c43c1d2a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc-match-helvetica.log
Type: text/x-log
Size: 84194 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120227/c43c1d2a/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120227/c43c1d2a/attachment-0001.pgp>

Hi,

Petr Gajdos wrote:
>[...]
> 0. Forget. It can''t work this way.
Well at the moment it''s just unsupported syntax.

I understand that some of fontconfig''s default configuration files used
to have some minor glitches here which have been fixed recently.

fontconfig''s implementation of <alias> parsing could probably be
changed
with some effort, but what''s wrong with just using a bunch of
<alias>
elements? These aren''t going to change so often anyway.

Raimund

Hi Raimund,

On Tue, Feb 28, 2012 at 10:25:34AM +0100, Raimund Steger
wrote:
> Petr Gajdos wrote:
> >[...]
> >0. Forget. It can''t work this way.
> 
> Well at the moment it''s just unsupported syntax.
> 
> fontconfig''s implementation of <alias> parsing could
probably be
> changed with some effort, but what''s wrong with just using a bunch
of
> <alias> elements? These aren''t going to change so often
anyway.
Yes, you are right, I will concentrate on more important todo I have
:-).

Thanks for your attention,
Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120229/2cd5f6da/attachment.pgp>