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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
