Bug 62422

Heh, apparently the bugzilla webform didn't understand the finnish characters I
entered, they ARE NOT "v" and "d".

The creation of fonts.scale and fonts.dir is intentional. These files are
not intended to be user editable in Red Hat Linux.  The xfs initscript
contains code which scans the directories listed in the font server
config file recreating fonts.scale and fonts.dir as needed.  This is
not a bug, but an intentional feature.

As a workaround, you can disable xfs, and have the X server serve fonts
directly if you prefer to manage these files yourself.  You may
possibly observe jerky mouse behaviour with X server served fonts however.

Mike, I can see why you've designed the xfs init script that way, but I'm a
little concerned for a couple of reasons:

1. External packages of fonts (notably the famous freefont and sharefont
packages) have extraneous files in them that cause mkfontdir to fail.  This is
really confusing, especially since the xfs script recreates the fonts.dir file
if *any* newer file is found in the directory ... including the "XftCache" file
that gets created if you use Xft for rendering.

[Arguably those packages *are* broken, and should have "fonts.scale" files as
well as fonts.dir, but I do think you're violating the "principle of least
surprise" here.]

2. The fonts.scale file can't readily be recreated except where TrueType fonts
are concerned, and you're making it impossible to distribute e.g. a package that
contains both TrueType and Type1 fonts; again, while this might be arguably
daft, it should work, providing the fonts.scale file is left untouched.

3. You need to exclude at least the "XftCache" file from the check for
non-TrueType fonts in the xfs script, because otherwise several of the font
paths in my catalogue are unnecessarily rebuilt every time I restart xfs.

4. This could be a major headache for people who want to mount /usr read-only.
The font paths ought really to be treated as read-only as far as starting
xfs/XFree86, especially since I might even be sharing those font paths with
other machines or even operating systems via NFS ... e.g. when I worked with
Solaris workstations in the past I used to share the whole /usr/openwin
hierarchy from one machine to several others to save disk space; I might wish to
use a font directory from a Sun box now, since I have a SPARC here at the moment
(and they do come with some nice fonts).

Indeed, the whole process is hackish, and does have some problems, however
fixing it to do the right thing in all cases is indeed complex.  I have
avoided trying to do so so far, as making a change could result in breaking
things much more horribly than they already are this late in a development
cycle.  This sort of level of change is something that requires a lot deeper
analysis to get "just right", taking into account not any one users particular
problem, but all users, including Chinese, Japanese, and Korean.  Getting
all of this right is quite a complex task, much moreso than what any one
simple fix for a given user's seemingly simple problem might provide.

Major xfs initscript changes should be done at the beginning of a
development cycle instead.  Personally I think this all should be done
inside xfs itself, and should take into account if /usr is read-only,
take into account disk space, /tmp free space, also run mkfontdir,
ttmkfdir and friends as needed, and also handle ttf/ttc fonts, and
various other oddities that creep up.

I'm reflagging this as an RFE, and deferring it for future investigation.

We've made xfs initscript enhancements every OS release or two for a
while now which have fixed this problem for a while now.

Rawhide contains the latest updates, which do a rather good job now.