Comment 63 for bug 521163

<email address hidden> wrote:
> I does not work out this way in practice. The source #1 source of conflict if
> some font packager making assumptions about other fonts with insufficient info,
> and having a centralized place does not stop him from making those assumptions
> (and CJK users are terrible about it: they're so frustrated they'll write any
> random crap without consideration for other users as long as it works on their
> system). On the contrary it means it puts those assumptions in the common file,
> making sure to break everyone else's config, even if they did not install this
> package.
>

I don't see your reasoning between advocating a non-centralized
config structure vs. preventing packager making assumptions.
Putting rules inside per-font config can be equally, or even more,
vulnerable to such personal bias. Centralized config file, managed
and reviewed by the upstream experienced managers, as advocated
in your later points, is exactly the reason I was trying so hard
to push this bug.

Don't make things sound more complicated, the submitted files are simply
1. a updated 65-nonlatin.conf (which is already in fontconfig), and
2. several CJK-specific rules with additional matching of the language tag

I don't think this is so different from the original fontconfig
philosophy.

> After a few years of looking after Fedora font packages I've never seen a
> centralized config file that was correct, it always reflected the bias of the
> last person to edit it, and it always got in the way of good packagers that
> tried to isolate their config without stepping on the toes of other packagers.
>

I do respect your work and principles to protect the fontconfig
structures for Fedora, but I disagree with your statement. I think
Ubuntu is doing a better job for CJK users with fontconfig. The
packages language-selector and fontconfig-voodoo are automatically
installed/executed for the selected CJK languages, and I believe
they are working just fine. From many Chinese Linux forums that I
participated, I can see a dominant majority of users are picking
up Ubuntu simply because of its CJK friendliness. I think
that's what Fedora should learn.

The proposed language-specific config files are simply improved
versions of Ubuntu's language-selector files (with additional lang
tag matching, so that it eliminates the needs for fontconfig-voodoo).

> IMHO the only way to bring some sanity to fontconfig is to define simple clear
> rules, and get everyone to follow them (because fontconfig syntax is flexible
> enough it us really easy to shoot oneself in the foot, and no using a single
> centralised file does not stop that).
>
> Such rules (again, IMHO) should be:
>
> 1. every font package includes the rules associated to its packaged font (no
> delegation to another package that *will* get out of sync and *will* be
> maintained by someone that has not got the fine knowledge about the font the
> actual font packager has)
>
> 2. you are forbidden to change in any way the priority of a font not included
> in your own package (at most you can declare your font is a valid substitute to
> another font)
>
> 3. you are only allowed to use reviewed fontconfig patterns in your fontconfig
> file (no "the rules everyone else uses are insufficient, I'll invent my own
> ones, it works on my computer with my set of fonts, what can go wrong?)
>
> 4. the only way fonts are priorized is the prefix of each fontconfig file,
> using documented rules (that means it's easy for distros to review their font
> setup, and change the prefix of one fontconfig file if it's wrong for them)
>

Again, as I said in the beginning, the whole point of this bug
is to propose a common set of CJK rules that are managed and
reviewed by the experienced users so that individual font package
have no need to overwrite with their own rules.

I don't know if you see a cycle here: the reason why individual
font packager write their own rules is because fontconfig is shipping
a 10 years old (or something like that) default font order
as in 65-nonlatin and it is extremely outdated; and now your
reasons for not making this update is because you are against
font packagers making their own rules. Your rule#2 will
not be going to work unless fontconfig is updated to reflect
these requests.