[Fontconfig] Lucida Sans/Grande/Unicode matching confusion

[Akira TAGOH]

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