[Fontconfig] complicated ordering

[Akira TAGOH]

On Thu, Jun 14, 2012 at 9:25 AM, Raimund Steger <rs at mytum.de> wrote:
> Coupling things like evaluation order of the rules, and where those rules
> are allowed to apply their edits (so that early rules can only prepend and
> later rules can only append) would seem like an awkward thing to do, I mean
> these are unrelated things after all.

Right. so ideally the rules before 50-user.conf would be minimal and
usually later rules after that wouldn't be affected to the user
configuration. but it looks like not at this moment.

> Wouldn't this be exactly what a number of people on this list have already
> been suggesting, i. e. using additional generic family names (in this
> example 'metrics-alias-Arial') for Helvetica-Lookalikes, Times-Lookalikes,
> Mincho-Lookalikes etc. so that candidates can substitute each other and
> fallbacks stay at the end of the group? And what's already employed by some
> of the other configuration files?

Maybe. I have no idea who takes this way though.

> Other suggestions for this particular topic I've heard: (1) drop all such
> rules and rely on distributions or ISVs or font metadata; (2) introduce new
> syntax to specify family equivalence.

I did suggest the former one here before..., but anyway.

> A possible over-engineered solution for family substitutes would be to
> promote fontconfig properties from list-valued to ordered-tree-valued, e. g.
> having
>
>  family: sans--HelveticaClass--Helvetica
>            |               `---Arial
>            +---LucidaClass-----Lucida Sans Unicode
>            |           `-------Lucida Grande
>            `---PGothic---------HG-PGothicB-Sun
>                   `------------MS PGothic
>
> where nodes in the tree could be moved as unit, i. e. all the Sanses can
> stay together if an 'edit' operates on that level, and edits can assign new
> parents and childs as additional modes.

Yes, I like this and actually thinking of the similar thing.

> But I think that would mean, where we've avoided doctoring around imaginary
> problems in the past, here we'd be happily inviting it, particularly (1)
> because generic families achieve the same just fine, (2) when I thought the
> general tone on this list was in favor of not introducing new classification
> logic on fontconfig's behalf, and its default rules were about to be
> stripped down...

Yeah... I felt same thing when I proposed in the past. so as Behdad
suggested, starting to work on the sort of fontconfig2 sounds like a
good idea.

> Apart from that I do wonder what a fontconfig2 could do better, other than
> fragment the landscape. The current one-pass forward-chaining rule engine
> design is simple enough and well-defined (and used everywhere else from
> procmail to iptables to Apache configuration etc.), and even if the API
> should someday be changed from A to B or a new way to prioritize fonts is
> introduced or whatever, there *should* always be the possibility for someone
> (who is not the superuser) to step in between any two rules and apply
> modifications right there.

True. having said that it's the fact that it also introduces
confusion. I suppose this is because it's not well-defined for the
case where it process the complicated rules. it would be one of issue
we can try to improve in the future.
For having any possibilities to override by users, we may need to have
well-managed hooks or prioritized config for each purposes, rather
than doing a lot in one file.

>
> Raimund



-- 
Akira TAGOH