[Fontconfig] please sort fonts.cache entries

[Egmont Koblinger]

Hi,

I don't know if my request is still relevant with the new fonts.cache-2
binary format, since I haven't looked at the binary format, but I guess it
is relevant.

I spent a few hours debugging a problem why gedit's (from gnome 2.12.x)
print preview shows garbage (each letter is converted to another one). Then
I realized that if I remove either TTF or Type1 or both fonts from
/usr/share/fonts (they were put there by X.Org 7.0) (and re-run fc-cache of
course) then it becomes okay. Strange, it's okay if none of these two font
types are installed, and also okay if only one (any) of them is installed.
But not if both. I also realized that these two directories both contained
a lot of -b&h-luxi mono-..... fonts, in different format, but with the same
core X font name.

I don't really know if it's a bug in X.org fonts or in fontconfig or in
gnome or in what else, but seemed that it gets confused about two different
implementations of the same font name. But I don't care (at this moment)
about it.

My next idea was to install both directories again and swap the order of
these two entries in fonts.cache-1. Previously Type1 preceeded TTF. I moved
Type1 down, below TTF. Suddenly gedit's print preview became perfect. Then I
reverted this change, it went wrong again. I can reproduce the bug any time
on my system, it depends on the order of fonts.cache entries.

This is a really ugly kind of bug, no matter whose bug it is. The order of
the unsorted directory listing may depend on millions of things, including
the installation order of packages, the filesystem type, or even the secret
random hash of newer ext3 filesystems. As a consequence, you may install the
same modern distro with the same setup on two same computers and gedit will
work correctly on one of them and will misbehave on the other.

Please don't give these really hardly traceable heisenbugs a chance. These
kind of bugs are hard to locate, hard to fix, hard to test, and have a
bigger chance that won't be seen at all before, let's say, a distro release.
So please avoid them by making sure that fc-cache always produces the same
cache file, no matter how the underlying filesystem works, no matter in
which order the fonts files were installed etc. In other words: please make
sure that the directories are scanned in a deterministic way (e.g. according
to the standard LC_ALL=C string sorting) or the resulted cache files are
sorted before being written.

I believe that implementing this isn't too hard, and the performance
regression caused by this is negligible (especially compared to the sleep(2)
in fc-config :-))))


Thanks,

Egmont