Bug 62422 - RFE: fonts.dir and fonts.scale files are re-created each time X is restarted.
Summary: RFE: fonts.dir and fonts.scale files are re-created each time X is restarted.
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 1.0
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2002-03-31 19:38 UTC by Dan Naumov
Modified: 2007-04-18 16:41 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-20 12:23:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dan Naumov 2002-03-31 19:38:02 UTC
Description of Problem:
Apparently, each time you restart X, it recreates fonts.dir and fonts.scale for
each font directory mentioned under the "catalogue"  section of /etc/X11/fs/config.

Version-Release number of selected component (if applicable):
XFree86 Version 4.2.0 (Unofficial Custom Build: 4.2.0-6.47) / X Window System

How Reproducible:

Steps to Reproduce:
1. Manuallly edit contents of fonts.dir/fonts.scale of a font directory that is
included in /etc/X11/fs/config "catalogue" section.
2. Restart X.

Actual Results:
fonts.dir and fonts.scale are recreated on X restart.

Expected Results:
fonts.dir and fonts.scale should've remained the same.

Additional Information:
If you wanted to be able to use finnish "v" and "d" symbols in AbiWord using
windows TTF fonts, you would have to manually edit fonts.dir and fonts.scale in
AbiWord fonts dir and remove all font lines that do not have "iso8859-1" at the
end". Refer to the file AbiWord_and_Unix_Fonts.zabw from the Abiword
documentation (version 0.9.2 and up) for more info on how Abiword deals with fonts.

This bug forces you to make both fonts.dir and fonts.scale read-only, because if
you don't do that, every time you restart X, you would have to edit fonts.dir
and fonts.scale again to make use of the character encoding you want, since X
recreates the files and fills them with unneeded entries.

Comment 1 Dan Naumov 2002-03-31 19:44:04 UTC
Heh, apparently the bugzilla webform didn't understand the finnish characters I
entered, they ARE NOT "v" and "d".

Comment 2 Mike A. Harris 2002-04-01 03:42:18 UTC
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.

Comment 3 Bill Crawford 2002-04-02 22:52:33 UTC
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).

Comment 4 Mike A. Harris 2002-04-03 15:05:20 UTC
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.

Comment 5 Mike A. Harris 2005-04-20 12:23:57 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.