[Fontconfig] Request for implementing font substitution for CJK fonts

[Raimund Steger]

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