Akira TAGOH wrote:
On Wed, May 2, 2012 at 12:52 AM, Raimund Steger<rs@xxxxxxxx> 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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
