[Fontconfig] matching multiple families in <alias> and <test> (was: Lucida Sans/Grande/Unicode matching confusion)
akira at tagoh.org
Thu May 3 06:36:23 PDT 2012
On Thu, May 3, 2012 at 9:48 AM, Raimund Steger <rs at mytum.de> wrote:
> It would, given this example config:
> 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
I guess we need more feedback, ideas for that...
More information about the Fontconfig