Comment 22 for bug 475889

Revision history for this message
In , Nicolas-mailhot-laposte (nicolas-mailhot-laposte) wrote :

This is fine in theory but who is going to write the quirks? We don't even have correct fontconfig configuration for all non-broken fonts in Fedora for example, let alone broken out-of-distribution fonts (and people have failed to find the correct settings for CJK for years).

If you want to write quirks, fontconfig has public documentation about its config syntax, we've added some fedora-side in fontpackages-devel, etc. So, nothing here to stop you now. But it is much easier for a font author to fix its font than to try to intercept all the ways applications query font metadata and fix it up at this level. (because fonts formats have accumulated over the years *many* different naming layers and you can't guess beforehand which one an app will use, or worse which *mix* of accesses it's going to try, assuming they are consistent when the data font side is not).

And it remains that the apps people complain of most (openoffice.org, firefox, inkscape, etc) have broken font handling (as in, they've implemented 80% of what's needed and someone who cares will do the rest) that shows breakage as soon as they get fed non-trivial fonts. And the breakage is *not* in fontconfig it's in the use of the library application-side. So it's *useless* to try to fix fonts of fake font characteristics at fontconfig level if you don't get the apps fixed first.

Complex fonts work in Adobe apps for example because Adobe did its work (1. released complex fonts *and* 2. added needed bits ui-side so the new features could be accessed). You're asking to avoid doing 2. and avoid fixing 1. when it has bugs and somehow magically get the same result as in Adobe apps through some fontconfig miracle. It's not going to happen. Fontconfig is good, but not that good.