Comment 92 for bug 521163

(In reply to comment #79)
> <email address hidden> wrote:

> I truly don't understand why this has to be done in a per-font format.
> Why Latin fonts can be listed in a preferred list in 60-latin.conf, but
> CJK fonts can not?

I don't like 60-latin.conf either but on a Fedora system we've made it mostly irrelevant. (I suppose we could also make your new files irrelevant, probably not what you want)

> The split files only increase the maintenance complexity, reduce
> the readability and gain very little (if there is any).

As I've stated (many times) my primary constraint is to have a smooth packaging flow where any font can be picked up by a packager and packaged quickly and independently. And the result is full-featured, not "it almost works but the remaining bits need integration by the fontconfig maintainer in its master files". We have one fontconfig maintainer who is awesome but also real busy working on all the text stack, whereas we have one packager per font package, and spreading the work as much as possible is basic common sense.

In such a model you have one font family per package only not huge collections of unrelated fonts (as I see very often in Debian).

This is how Fedora has been working in the past two years.

Anything that requires editing a file shared by multiple packages, instead of letting each package drop its own file, is contrary to this workflow.

Anything that implies it is ok to change font rules for fonts in other packages, such as mixing multiple font names in a single file, is a receipe for packager conflicts

Anything that implies you need to edit a file shared by multiple packages, such as the files you propose integrating, is an impediment to this workflow because people wait for the central authority to move before doing anything

Besides from a support POW, is is a lot easier to ask users to rename one symlink and re-test, than tell them to edit a font list in XML format. So this config style also helps after the packaging.

> The scheme makes this setup robust because

The scheme is not robust. The more times you repeat a font name, the more times you introduce room for human mistakes and someone editing one instance of your declarations but not the other.

It is a good idea to fall back on fonts declared in other generic stacks before trying any random un-declared font. It is a bad idea to do it via explicit multiple font declarations