[Fontconfig] Lucida Sans/Grande/Unicode matching confusion
akira at tagoh.org
Tue May 1 19:26:41 PDT 2012
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
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"
> "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
> I. e. maybe something like having FcConfigMatchValueList() return first
> _and_ last match in the actual value list and use the latter for append
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.
More information about the Fontconfig