Fontconfig - Apr 2012 - Lucida Sans/Grande/Unicode matching confusion

Hello, my first post.

I come across a lot of presentation PDFs using Lucida Sans fonts. I
didn''t have the font in Kubuntu 12.04 amd64, but my legal paid-for
Windows Vista partition has a /Windows/Fonts/l_10646.ttf that fc-scan
identifies as family "Lucida Sans Unicode". So risking death by
lawyers I installed this as a personal font to ~/.fonts using the KDE
fontinst Control Module, and now
    %  fc-match "Lucida Sans Unicode"
returns
    l_10646.ttf: "Lucida Sans Unicode" "Normal"

Great... except fontconfig won''t use this font for the many documents
and web pages specifying just "Lucida Sans" or the Mac OS X version
"Lucida Grande".  fc-match confirms it still uses
    DejaVuSans.ttf: "DejaVu Sans" "Book"
and indeed DejaVu Sans appears to be the fallback font for them in
Inkscape and Firefox.[**]

The situation where someone has one Lucida Sans font but not the
others is extremely common as there are numerous blog posts discussing
the ordering of these fonts in CSS to get the best results, e.g.
<http://qelix.com/blog/tag/lucida-grande/>. Perhaps fontconfig should
have a default rule supporting this situation? I''m clueless but it
would seem to be some kind of <alias> grouping all three Lucida Sans
into a pseudo-family "variations on Lucida Sans" that says if
you''ve
got one of the fonts, then use it for the other two.  But none of the
existing rules seem to do this, they assume you have one font that can
default for others, e.g. /etc/fonts/conf.avail/30-urw-aliases.conf

[**] Do sans serif fonts all default to DejaVu Sans because
/etc/fonts/conf.avail/60-latin.conf has a prefer section that lists it
first?
        <alias>
                <family>sans-serif</family>
                <prefer>
                        <family>DejaVu Sans</family>
                        <family>Bitstream Vera Sans</family>
                        ...

I read the doc in
file:////usr/share/doc/fontconfig/fontconfig-user.html and can''t
figure out from it what to do; it doesn''t have recipes for things like
this, and it has been found that passive voice is to be avoided.

Thanks greatly for any help.
--
=S Page

Hi,

On Mon, April 30, 2012 02:53, S Page wrote:
> [...]
>
> [**] Do sans serif fonts all default to DejaVu Sans because
> /etc/fonts/conf.avail/60-latin.conf has a prefer section that lists it
> first?
>         <alias>
>                 <family>sans-serif</family>
>                 <prefer>
>                         <family>DejaVu Sans</family>
>                         <family>Bitstream Vera Sans</family>
>                         ...
Yes, this should be the place that has the most direct impact.

If all you want is an alias for "Lucida Sans", the following in
~/.fonts.conf should work:

  <alias>
  <family>Lucida Sans</family>
  <accept>
    <family>Lucida Sans Unicode</family>
    <!-- or whatever variant you have -->
  </accept>
  </alias>

However: The spelling "Lucida Sans" is used by TTF fonts bundled with
certain Sun software (Solaris, JDK), so maybe you already have them, and
adding something like

  <dir>/usr/java/jre/lib/fonts</dir>

to ~/.fonts.conf would even work?

As the blog article you mentioned suggests, it would be a good idea for
webpages that want to be portable to specify the major Lucida variants in
their CSS rules, not just one of them. Whether fontconfig needs new
default rules for Lucida or even a new generic family name, I don''t
know.
I think generic names are meant to work across all locales, and the other
aliases are typically metric-compatible.

Raimund


-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346

On Mon, Apr 30, 2012 at 04:45, Raimund Steger <rs at mytum.de>
wrote:
> If all you want is an alias for "Lucida Sans", the following in
> ~/.fonts.conf should work:
> ...
Thanks! I mention both Lucida Sans and Lucida Grande in one alias and
it seems to work:
 <alias>
  <family>Lucida Sans</family>
  <family>Lucida Grande</family>
  <accept>
   <family>Lucida Sans Unicode</family>
  </accept>
 </alias>
> However: The spelling "Lucida Sans" is used by TTF fonts bundled
with
> certain Sun software (Solaris, JDK), so maybe you already have them, and
> adding something like
>
> ?<dir>/usr/java/jre/lib/fonts</dir> ...
There don''t appear to be any fonts in my "IcedTea6" OpenJDK.
> Whether fontconfig needs new
> default rules for Lucida or even a new generic family name, I
don''t know.
The current behavior isn''t "do the right thing" for a naive
user. If I
install a font that is obviously much closer to other font families
than the O.S. default, it''s strange that fontconfig doesn''t
pick it
unless I write some configuration info.

The rule /etc/fonts/conf.avail/30-metric-aliases.conf does the right
thing to "alias similar/metric-compatible families from various
sources" for the big guns Helvetica-Times-Courier, maybe the Lucida
Sans discontinuity between Windows, Mac, & Java is important enough to
add it. But then why not Garamond-alikes, Futura variants, etc. as
well.

Is fontconfig even intended to know about font families that aren''t
installed so it can pick the closest matching font given a name?
That''s been the PANOSE/OS2 sFamilyClass dream for decades; it seems
from a few web documents using the abandoned CSS panose-1 property
that Lucida and Lucida Sans share the same "2 11 6 2 3 5 4 2 2 4"
panose-1 digits.

--
=S Page

On Tue, May 1, 2012 at 10:04 AM, S Page <skierpage at gmail.com>
wrote:
> The current behavior isn''t "do the right thing" for a
naive user. If I
> install a font that is obviously much closer to other font families
> than the O.S. default, it''s strange that fontconfig
doesn''t pick it
> unless I write some configuration info.
I think it''s a known and long standing issue :
https://bugs.freedesktop.org/show_bug.cgi?id=13416
it needs to be fixed/improved in the future.
> Is fontconfig even intended to know about font families that
aren''t
> installed so it can pick the closest matching font given a name?
It doesn''t do more than comparing the names for family name so far,
unless having any particular rules for alternatives, as you
experienced.
> That''s been the PANOSE/OS2 sFamilyClass dream for decades; it
seems
> from a few web documents using the abandoned CSS panose-1 property
> that Lucida and Lucida Sans share the same "2 11 6 2 3 5 4 2 2 4"
> panose-1 digits.
We have a RFE for that too I think...

-- 
Akira TAGOH

S Page wrote:
> On Mon, Apr 30, 2012 at 04:45, Raimund Steger<rs at mytum.de>  wrote:
>> If all you want is an alias for "Lucida Sans", the following
in
>> ~/.fonts.conf should work:
>> ...
>
> Thanks! I mention both Lucida Sans and Lucida Grande in one alias and
> it seems to work:
>   <alias>
>    <family>Lucida Sans</family>
>    <family>Lucida Grande</family>
>    <accept>
>     <family>Lucida Sans Unicode</family>
>    </accept>
>   </alias>
Hm, normally only one <family> is supported in the left hand side of an 
alias rule I think. See fontconfig-user.html or:

   http://thread.gmane.org/gmane.comp.fonts.fontconfig/3741
>
>> However: The spelling "Lucida Sans" is used by TTF fonts
bundled with
>> certain Sun software (Solaris, JDK), so maybe you already have them,
and
>> adding something like
>>
>>   <dir>/usr/java/jre/lib/fonts</dir>  ...
>
> There don''t appear to be any fonts in my "IcedTea6"
OpenJDK.
I see, but if you should someday be in the need of further improving 
your legal situation (over using a borrowed copy of Lucida Sans 
Unicode), installing an Oracle JDK could be an idea.

Raimund

On Tue, May 1, 2012 at 6:07 PM, Raimund Steger <rs at mytum.de>
wrote:
> Hm, normally only one <family> is supported in the left hand side of
an
> alias rule I think. See fontconfig-user.html or:
>
> ?http://thread.gmane.org/gmane.comp.fonts.fontconfig/3741
I''ve read threads and code again, I think this is actually a bug.
strictly speaking, <alias> is capable to have multiple <family>
elements in it. but current implementation tries to do prepend/append
at the first element of <family> anyway. this is why it works for one
but not for other. I''ll fix that.

-- 
Akira TAGOH

Well, actually it''s not alias specific but can see same behavior when
having multiple strings in <test>.

https://bugs.freedesktop.org/show_bug.cgi?id=33644#c12 and
https://bugs.freedesktop.org/show_bug.cgi?id=33644#c17 may helps to
understand what happened there.

On Tue, May 1, 2012 at 7:11 PM, Akira TAGOH <akira at tagoh.org>
wrote:
> On Tue, May 1, 2012 at 6:07 PM, Raimund Steger <rs at mytum.de>
wrote:
>> Hm, normally only one <family> is supported in the left hand side
of an
>> alias rule I think. See fontconfig-user.html or:
>>
>> ?http://thread.gmane.org/gmane.comp.fonts.fontconfig/3741
>
> I''ve read threads and code again, I think this is actually a bug.
> strictly speaking, <alias> is capable to have multiple <family>
> elements in it. but current implementation tries to do prepend/append
> at the first element of <family> anyway. this is why it works for one
> but not for other. I''ll fix that.
>
> --
> Akira TAGOH


-- 
Akira TAGOH

Hi,

Akira TAGOH wrote:
> Well, actually it''s not alias specific but can see same behavior
when
> having multiple strings in<test>.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=33644#c12 and
> https://bugs.freedesktop.org/show_bug.cgi?id=33644#c17 may helps to
> understand what happened there.
I''ve read the comments now, and it sounds rather difficult to get it 
right. (I typically work around such situations by duplicating rules in 
the config, i. e. effectively appending/prepending my edits several 
times during config substitution.)

I think that most users, when they use multiple families in the upper 
part of <alias>, think of something like:

   "Now if I use <accept>, then append after the last occuring
    value out of the ones I just specified"

and

   "If I use <prefer>, then prepend before the first occuring
    value out of the ones I specified"

I. e. maybe something like having FcConfigMatchValueList() return first 
_and_ last match in the actual value list and use the latter for append 
edits.

But I don''t really know. I''m fine with the current
implementation and
it''s easy to avoid such configuration issues anyway.

Raimund

On Wed, May 2, 2012 at 12:52 AM, Raimund Steger <rs at mytum.de>
wrote:
> I''ve read the comments now, and it sounds rather difficult to get
it right.
> (I typically work around such situations by duplicating rules in the
config,
> i. e. effectively appending/prepending my edits several times during config
> substitution.)
Well, only for the user-side configuration, they could still use
"prepend_first" to apply their rules as the first priority.
it''s
however a bad idea for the system-wide configuration IMHO. but anyway.
> I think that most users, when they use multiple families in the upper part
> of <alias>, think of something like:
>
> ?"Now if I use <accept>, then append after the last occuring
> ? value out of the ones I just specified"
>
> and
>
> ?"If I use <prefer>, then prepend before the first occuring
> ? value out of the ones I specified"
Hmm, if people really expects to do so, having separate rules behaves
differently then.
> I. e. maybe something like having FcConfigMatchValueList() return first
> _and_ last match in the actual value list and use the latter for append
> edits.
What if there are <family> lines more than two?

Anyway, I think we may have some options so far:

1. Drop FcOpComma and warns it''s not supported syntax.

2. add an attribute to <edit> and <alias> to let fontconfig know
where
to edit. e.g. pos="first|last|binding|all"

3. keep current behavior

there may be more though. but I don''t think taking option 3 is a good
idea because many people is asking this many times. it has to be
improved. if making it controllable as option 2 is complicated, that
may be better getting rid of this feature, even though it would really
be convenient if it _works_.
>
> But I don''t really know. I''m fine with the current
implementation and it''s
> easy to avoid such configuration issues anyway.
>
> Raimund

-- 
Akira TAGOH

Le Lun 30 avril 2012 02:53, S Page a ?crit :
> Perhaps fontconfig should
> have a default rule supporting this situation? I''m clueless but it
> would seem to be some kind of <alias> grouping all three Lucida Sans
> into a pseudo-family "variations on Lucida Sans" that says if
you''ve
> got one of the fonts, then use it for the other two.  But none of the
> existing rules seem to do this, they assume you have one font that can
> default for others, e.g. /etc/fonts/conf.avail/30-urw-aliases.conf
You can write family-specific rules that do not depend on generic families

http://dejavu.svn.sourceforge.net/viewvc/dejavu/trunk/dejavu-fonts/fontconfig/57-dejavu-sans.conf

Regards,

-- 
Nicolas Mailhot

Akira TAGOH wrote:
> On Wed, May 2, 2012 at 12:52 AM, Raimund Steger<rs at mytum.de> 
wrote:
>> [...]
>> I think that most users, when they use multiple families in the upper
part
>> of<alias>, think of something like:
>>
>>   "Now if I use<accept>, then append after the last occuring
>>    value out of the ones I just specified"
>>
>> and
>>
>>   "If I use<prefer>, then prepend before the first occuring
>>    value out of the ones I specified"
>
> Hmm, if people really expects to do so, having separate rules behaves
> differently then.
That''s true, it would be a different behavior. Hm, now I''m not
so sure
anymore. (Many users probably don''t really realize that they deal with
a
list of families they compare with, not just one.)
>> I. e. maybe something like having FcConfigMatchValueList() return first
>> _and_ last match in the actual value list and use the latter for append
>> edits.
>
> What if there are<family>  lines more than two?
It would, given this example config:

   <alias>
     <family>Family1</family>
     <family>Family2</family>
     <family>Family3</family>
     <family>Family4</family>
     <family>Family5</family>
     <accept><family>AppendedFamily1</family>
             <family>AppendedFamily2</family></accept>
     <prefer><family>PrependedFamily1</family>
             <family>PrependedFamily2</family></prefer>
   </alias>

and this query:

   FC_DEBUG=1 fc-match Family0,Family1,Family6,Family4,Family3,Family7

result in this after substitution:

   [...]
    family: "Family0"(s) "PrependedFamily1"(w)
"PrependedFamily2"(w)
"Family1"(s) "Family6"(s) "Family4"(s)
"Family3"(s) "AppendedFamily1"(w)
"AppendedFamily2"(w) "Family7"(s) "Bitstream Vera
Sans"(w) "DejaVu
Sans"(w) "Verdana"(w) "Arial"(w) "Albany
AMT"(w) "Luxi Sans"(w) "Nimbus
Sans L"(w)
   [...]

i. e. prepend/append occurs around the leftmost/rightmost actually 
matching family of the list that was specified in the original pattern.

I just started changing fccfg.c to test it, when I noticed that if some 
rather standard/fallback family occurs in a test, append edits would 
always be applied after its last occurence which will be pretty close to 
the end of the whole list, possibly also not what users expect. So maybe 
the idea with using the binding isn''t so bad :-)
> Anyway, I think we may have some options so far:
>
> 1. Drop FcOpComma and warns it''s not supported syntax.
>
> 2. add an attribute to<edit>  and<alias>  to let fontconfig
know where
> to edit. e.g. pos="first|last|binding|all"
>
> 3. keep current behavior
>
> there may be more though. but I don''t think taking option 3 is a
good
What I can also think of (at least for <alias>), is to not use 
FcOpComma, but create as many FcTest objects (and add all of them with 
FcConfigAddEdit) in FcParseAlias as there are families in the upper part 
of <alias>, thus simulating what a user would do creating separate rules 
for all of them.

Raimund

On Thu, May 3, 2012 at 9:48 AM, Raimund Steger <rs at mytum.de>
wrote:
> It would, given this example config:
>
> ?<alias>
> ? ?<family>Family1</family>
> ? ?<family>Family2</family>
> ? ?<family>Family3</family>
> ? ?<family>Family4</family>
> ? ?<family>Family5</family>
> ? ?<accept><family>AppendedFamily1</family>
> ? ? ? ? ? ?<family>AppendedFamily2</family></accept>
> ? ?<prefer><family>PrependedFamily1</family>
> ? ? ? ? ? ?<family>PrependedFamily2</family></prefer>
> ?</alias>
>
> and this query:
>
> ?FC_DEBUG=1 fc-match Family0,Family1,Family6,Family4,Family3,Family7
>
> result in this after substitution:
>
> ?[...]
> ? family: "Family0"(s) "PrependedFamily1"(w)
"PrependedFamily2"(w)
> "Family1"(s) "Family6"(s) "Family4"(s)
"Family3"(s) "AppendedFamily1"(w)
> "AppendedFamily2"(w) "Family7"(s) "Bitstream Vera
Sans"(w) "DejaVu Sans"(w)
> "Verdana"(w) "Arial"(w) "Albany AMT"(w)
"Luxi Sans"(w) "Nimbus Sans L"(w)
> ?[...]
>
> i. e. prepend/append occurs around the leftmost/rightmost actually matching
> family of the list that was specified in the original pattern.
Aha. that looks reasonable to me. particularly if the result is
considered as the intersection of the given pattern and the string
sets in <test>.
> I just started changing fccfg.c to test it, when I noticed that if some
> rather standard/fallback family occurs in a test, append edits would always
> be applied after its last occurence which will be pretty close to the end
of
> the whole list, possibly also not what users expect. So maybe the idea with
> using the binding isn''t so bad :-)
Hmm, although, speaking of the above example, referring the binding
may be a bit far to what you expect at least.
> What I can also think of (at least for <alias>), is to not use
FcOpComma,
> but create as many FcTest objects (and add all of them with
FcConfigAddEdit)
> in FcParseAlias as there are families in the upper part of <alias>,
thus
> simulating what a user would do creating separate rules for all of them.
Sure. that would be an idea though, as it''s documented, <alias>
has to
be kept as a syntactic sugar. so needs to change the behavior of
FcOpComma then.

I guess we need more feedback, ideas for that...
>
> Raimund
-- 
Akira TAGOH

Akira TAGOH wrote:
> On Thu, May 3, 2012 at 9:48 AM, Raimund Steger<rs at mytum.de> 
wrote:
>> [...]
>>
>> i. e. prepend/append occurs around the leftmost/rightmost actually
matching
>> family of the list that was specified in the original pattern.
>
> Aha. that looks reasonable to me. particularly if the result is
> considered as the intersection of the given pattern and the string
> sets in<test>.
Right, that was the word :-)
But I don''t think it''s a good idea anymore, because I
can''t think of any
way to consistently deal with "assign" edits then.
>> What I can also think of (at least for<alias>), is to not use
FcOpComma,
>> but create as many FcTest objects (and add all of them with
FcConfigAddEdit)
>> in FcParseAlias as there are families in the upper part
of<alias>, thus
>> simulating what a user would do creating separate rules for all of
them.
>
> Sure. that would be an idea though, as it''s
documented,<alias>  has to
> be kept as a syntactic sugar. so needs to change the behavior of
> FcOpComma then.
True, it''s not a good approach to invalidate existing user-knowledge 
about the relationship of <alias> and <match>.

Maybe when going through the FcOpComma operands, one could tag the 
matching FcValueList''s somehow and loop precisely over them for the 
following prepend/append/assign edits.

Raimund

Hi,

Raimund Steger wrote:
> [...]
>
> Maybe when going through the FcOpComma operands, one could tag the
> matching FcValueList''s somehow and loop precisely over them for
the
> following prepend/append/assign edits.
I''ve now tried to modify fccfg.c along those lines and attached an idea
of how I think it might work.
It''s probably far from being particularly elegant (or bug-free), but in
a simple test case (matching a number of families through multi-family 
<alias> and <test>) it seems to do what I have in mind:

(1) Save away every match in the test (but at most one per FcOpComma 
operand). For this, FcSubState is updated to allow a linked list that 
contains additional malloc''ed elements in the case of additional
matches.

(2) For assign/prepend/append edits, go through that linked list and 
apply every edit once for every match, instead of once for the test. 
This means, it should simulate the behavior of separate rules.

It''s not extensively tested, but maybe it can further fuel the
discussion...

Raimund

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc_multivaluetest_rs20120510_0.patch
Type: text/x-patch
Size: 8217 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120511/788834d6/attachment.bin>

Thanks for trying.

FWIW I noticed that what I mentioned at Bug#33644 has inconsistency in
the usage of qual. it is, even though qual="any" and
qual="all"
affects values in <test>, qual="first" and
qual="not_first" actually
affects values in the pattern. I suppose it may be a bug in FcOpComma
then. given that it is, this rule:

  <test name="family" qual="all">
    <string>blah blah blah</string>
  </test>

may expects to match when all of values in the pattern contains "blah
blah blah". I''m not quite sure if it''s really likely to
happen and I
totally missed what FcOpComma is for.

This reminds me that we have to restructure the expression rules in
the configuration, including any possibilities to introduce new syntax
and we need to discuss first how to build the rules for "A AND B" and
"A OR B" with/without FcOpComma say and may need to discuss if we
should make the implicit rules clear in the configuration too, like
the position of element that <edit> take effects as we are discussing
now. we can go back to the alias thing after that because of its
purpose.

On Fri, May 11, 2012 at 10:10 AM, Raimund Steger <rs at mytum.de>
wrote:
> Hi,
>
> Raimund Steger wrote:
>>
>> [...]
>>
>>
>> Maybe when going through the FcOpComma operands, one could tag the
>> matching FcValueList''s somehow and loop precisely over them
for the
>> following prepend/append/assign edits.
>
>
> I''ve now tried to modify fccfg.c along those lines and attached an
idea of
> how I think it might work.
> It''s probably far from being particularly elegant (or bug-free),
but in a
> simple test case (matching a number of families through multi-family
<alias>
> and <test>) it seems to do what I have in mind:
>
> (1) Save away every match in the test (but at most one per FcOpComma
> operand). For this, FcSubState is updated to allow a linked list that
> contains additional malloc''ed elements in the case of additional
matches.
>
> (2) For assign/prepend/append edits, go through that linked list and apply
> every edit once for every match, instead of once for the test. This means,
> it should simulate the behavior of separate rules.
>
> It''s not extensively tested, but maybe it can further fuel the
discussion...
>
> Raimund
>


-- 
Akira TAGOH

Akira TAGOH wrote:
> Thanks for trying.
>
> FWIW I noticed that what I mentioned at Bug#33644 has inconsistency in
> the usage of qual. it is, even though qual="any" and
qual="all"
> affects values in<test>, qual="first" and
qual="not_first" actually
> affects values in the pattern. I suppose it may be a bug in FcOpComma
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.

I''ve always found the qual''s in fontconfig to behave as I
expected, i.
e. to specify whether the (single) value from <test> should match at:

* first position
* 2nd+ position
* all positions
* any position

in the pattern.
So qual="all" is mostly useful for compare="not_eq", or if
the preceding
rule used mode="assign_replace" to remove all other fallback stuff
from
the element.

Using other qual''s than "any" with FcOpComma in <test>
should trigger
some pretty awkward behavior at the moment, because the order of 
FcOpComma operands will decide which one is used to check for the 
position(s) in the pattern, which is totally counter-intuitive (for 
example, I think for qual="all" the last operand would need to get the
match, while for "first"/"not_first" it''s likely
different).

But it''s not allowed currently anyway ;-)
> This reminds me that we have to restructure the expression rules in
> the configuration, including any possibilities to introduce new syntax
> and we need to discuss first how to build the rules for "A AND B"
and
> "A OR B" with/without FcOpComma say and may need to discuss if we
> should make the implicit rules clear in the configuration too, like
> the position of element that<edit>  take effects as we are discussing
> now. we can go back to the alias thing after that because of its
> purpose.
You mean using <or> etc. not only to calculate ordinal FcTypeBool 
values, but also for disjunction of subexpressions in <test>?
But still, as you said, the problem where to apply edits if more than 
one value matched remains...

Raimund

On Wed, May 16, 2012 at 9:11 AM, Raimund Steger <rs at mytum.de>
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. that''s why I''m a bit concerned about the
inconsistency.
otherwise all of the combinations for qual''s and mode''s should
be
documented to avoid confusion. that would helps us to remember how it
is supposed to work ;)
> Using other qual''s than "any" with FcOpComma in
<test> should trigger some
> pretty awkward behavior at the moment, because the order of FcOpComma
> operands will decide which one is used to check for the position(s) in the
> pattern, which is totally counter-intuitive (for example, I think for
> qual="all" the last operand would need to get the match, while
for
> "first"/"not_first" it''s likely different).
>
> But it''s not allowed currently anyway ;-)
Hmm, I''m not sure. it may be easier to address this if we leave the
decision of where the position <edit>s would be applied on to the
users?
> You mean using <or> etc. not only to calculate ordinal FcTypeBool
values,
> but also for disjunction of subexpressions in <test>?
Yes, something like that. it may be needed particularly if using qual
for that purpose is a bad idea.
> But still, as you said, the problem where to apply edits if more than one
> value matched remains...
That''s true. it may be relevant each other but should be a separate
issue.

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.

-- 
Akira TAGOH

Akira TAGOH wrote:
> On Wed, May 16, 2012 at 9:11 AM, Raimund Steger<rs at mytum.de> 
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

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