BlissSam wrote:
[...] Mapping specific to generic, and map generic to specific,
You summarized a correct way of doing this in a few words -- isn't that simple enough? Definitely something for distribution maintainers to tackle.
As for providing a configuration tool -- the problem I see is: If it supports all of the DTD, it won't be substantially less complex than editing the XML file by hand. If it however uses a simplified syntax, e. g. only using family equivalence classes or something -- it'll be one-way, i. e. not fully compatible with existing XML, and what's more, users might still get unexpected results that they cannot explain if some other rule outmatches one of their families.
Of course that doesn't mean it's completely unfeasible :-) Didn't libeasyfc do something similar?
(Another option could still be a plain old FAQ to make people easier with the XML or maybe... er... a Wiki.)
And the font substitution can be more smart, user can specify whether only to fallback when a font is missing, or to replace whenever that font is installed;
I think that would be what <edit mode="append"> vs. <edit mode="prepend"> do.
also, some users may want to substitute only on screen or when printing.
You mean a "media" property like CSS has, to sort out the occasional bitmap font arriving at the printer? Sounds useful, but would depend on application support. Theoretically, applications could already indicate high-DPI targets such as paper by sending a dpi property to fontconfig, which would be >= 600 for printers, and which users could react to in their config. If they don't do that at the moment (which sounds like a shame but is probably reality), I'm not sure whether they'll use even another property.
Raimund _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
