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 _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
