[Fontconfig] complicated ordering

[Raimund Steger]

Hi,

Behdad Esfahbod wrote:
> My first take is, if we're ever going to change this considerably, we should
> go back and rethink the problem, possibly replace both the language and the
> API....  Ie. fontconfig2.
>
> b
>
> On 06/12/2012 10:56 PM, Akira TAGOH wrote:
>> Hi,
>>
>> fontconfig will read the xml files according to the alphanumerical
>> ordering. one may expects that the earlier one would have a priority
>> than later one. actually this is true for "prepend", "assign_replace"
>> and "append_last" too in some cases. but not for "prepend_first",
>> [...]

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.

>> Well, I'm wondering if we may need to change the data structure to
>> group according to the edit mode or so for long term solution. for
>> short term solution, the above case can be improved with the sort of
>> "hook" as the following. e.g. 30-metrics-alias.conf to:
>>
>> 30-0-metrics-alias.conf:
>> <match>
>>    <test name="family"><string>Arial</string></test>
>>    <edit name="family" mode="append" binding="same">
>>      <string>metrics-alias-Arial</string>
>>    </edit>
>> </match>
>>
>> 30-1-metrics-alias-arial.conf:
>> <match>
>>    <test name="family"><string>metrics-alias-Arial</string></test>
>>    <edit name="family" mode="prepend" binding="same">
>>      <string>Liberation Sans</string>
>>    </edit>
>> </match>
>>  [...]

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?

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 wouldn't object any number of additional generic or 'marker' families 
being introduced to keep fallbacks in their place, and for me they don't 
even need to be deleted in the end, which would have the advantage that 
third parties could place their fonts around the generic names they deem 
the most fitting candidates as they drop their snippets into 
/etc/fonts/conf.d/.

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.

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...

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.

Raimund