|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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