Bug 77492 - xfs excludes directories that contain bad true type font file information
Summary: xfs excludes directories that contain bad true type font file information
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ttmkfdir
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Yu Shao
QA Contact: David Lawrence
Depends On: 77272
TreeView+ depends on / blocked
Reported: 2002-11-07 22:16 UTC by Michael Lee Yohe
Modified: 2007-04-18 16:48 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-10-28 18:56:36 UTC

Attachments (Terms of Use)

Description Michael Lee Yohe 2002-11-07 22:16:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
I have noticed that the XFree86-xfs package is not listed for selection in
Bugzilla (otherwise, I would have selected that instead).

Many people seem to be having a problem getting fonts to work under Red Hat
Linux 8.0 - more specifically, it would appear that Xft2 is not having problems
seeing new true type fonts (copying them into the ~/.fonts directory is working
well), but non-Xft2 applications (including all of X's own utilities like
xlsfonts) cannot see fonts that are located in a true type font directory
installed manually by the user.

The thread started when I had the same problem as the reporters with Bug 75202
(After installing ttf in ~/.fonts, not visible via xlsfonts) and Bug 76828
(TrueType fonts not working with non-Xft2 apps).  Having installed fonts on many
different Red Hat Linux platforms (pre-8.0) before, I found this to be an odd
problem - so I checked Bugzilla.

When I came across Bugs 75202 and 76828, the "solution" to the problem was
essentially that the reporter did not do something correctly to properly install
fonts for xfs.  The only thing I could determine that the original reporters
were failing to do was to create the necessary fonts.dir file (and fonts.scale
file) so that xfs would have the proper format for the true type fonts in the
new directory.

Unfortunately this does not always solve the problem.  mharris stated, 'I can
change the resolution to WORKSFORME if you like, or perhaps
WORKSFOREVERYONEBUTYOU."  Let's define the steps known to install fonts for
non-Xft2 applications (these can be found in FAQs):

1) create a directory to contain your new true type fonts
# mkdir /usr/share/fonts/ttf

2) copy your fonts into the newly created directory
# cp *.ttf *.TTF /usr/share/fonts/ttf

3) create the necessary fonts.dir file for xfs
# cd /usr/share/fonts/ttf; ttmkfdir -o fonts.dir

Note: I found that the ttmkfdir application that comes with Red Hat Linux 8.0
reported a SIGABRT.  So I downloaded the ttmkfdir application from the xfsft web
site: http://www.joerg-pommnitz.de/TrueType/xfsft.html).  Their utility does not
produce an SIGABRT - **this is significant - continue reading**.

4) go ahead and create the fonts.scale symbolic link (for grins)
# ln -s fonts.dir fonts.scale

5) now that we have our new directory, add it to xfs's configuration using Red
Hat's chkfontpath utility
# chkfontpath --add=/usr/share/fonts/ttf

6) verify that it exists
# chkfontpath
8: /usr/share/fonts/ttf

7) restart the font server
# /etc/init.d/xfs restart

8) check to see if your font was installed
# xlsfonts | grep -i <name of a font you just installed>

When I get to this point, I should have seen a font I just installed.  However,
this is not always the case.  So the resolution could be
WORKSFOREVERYONEBUTYOUSOMETIMES - here's what I have found to be the problem:

I had about 200 fonts I wanted to install.  When I performed the above steps -
none of the fonts in the directory I had just added showed up.  When modifying
fonts.conf (for fontconfig/Xft2) to add the directory, all the fonts showed up
for Xft2 enabled applications.  Here's the big deal:

Some true type fonts are useable but do not generate the proper
"-microsoft-tahoma-medium-r-normal--0-0-0-0-p-0-iso8859-9"-like information.  If
one of the fonts has a bad entry in the file (or if the file itself is
corrupted) xfs will completely ignore the entire directory.  To test this
theory, I copied a single font over to my directory (Microsoft Tahoma) to my
/usr/share/fonts/ttf directory and re-performed the above steps.  Xft2 enabled
applications saw Tahoma.  **AND** now non-Xft2 applications saw Tahoma.

The culprit font (or fonts) will prevent xfs from utilizing the fonts in a
particular directory.  Here's what I've also found out:

Red Hat's ttmkfdir will produce a SIGABRT when generating the fonts.dir
information if it runs into one of these culprit font files.  The ttmkfdir that
comes from the aforementioned website apparently ignores these flaws and
continues generating a fonts.dir file anyway.  For example:

# cd /usr/share/fonts/ttf
# ttmkfdir.xfsft -o fonts.dir
unknown font foundry code PYRS
unknown font foundry code PL
unknown font foundry code PL
unknown font foundry code NICK
unknown font foundry code SFT
unknown font foundry code PYRS
unknown font foundry code NICK
unknown font foundry code SFT
unknown font foundry code GEM
unknown font foundry code HL
unknown font foundry code HL
unknown font foundry code PYRS
unknown font foundry code SEF
unknown font foundry code ERUC
unknown font foundry code ERUC
unknown font foundry code GEM
unknown font foundry code GEM
unknown font foundry code FROG
unknown font foundry code GEM

# ttmkfdir.redhat -o fonts.dir

Red Hat's ttmkfdir should be modified to give an explanation to the user "<font
name> is corrupted.  Please remove this font before continuing." or it should
simply skip the file, informing the user that it has done just that.  I have
filed Bug 77491 for this anomaly.

If someone does already have a fonts.dir file that a corrupted data entry, xfs
will ignore the directory without providing a warning to the user (or simply
skipping the corrupted entry).  xfs should generate an error code and tell X to
let the user know that a font in one of its directories is malformed and cannot
be used.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Have a directory that contains a fonts.dir file that references a corrupted font.
2. Configure xfs to use this font directory.
3. Restart xfs.

Actual Results:  No fonts in the directory will be usable by xfs.

Expected Results:  All fonts which are not corrupted should be available to be
used.  All corrupted font entries should be ignored and the user informed that
there is a problem with a font file (or files) in a particular directory.

Additional info:

Comment 1 Mike A. Harris 2002-11-09 01:47:05 UTC
Yeah, thats nice that the ttmkfdir util you found doesn't have the
problem that you're describing in our ttmkfdir.  What you don't realize
however, is that using that utility in all of the fonts that come with
Red hat Linux breaks Korean, Chinese, Japanese, Thai fonts, as well
as various others such as Russian (Cyrillic).  That is why we have
the utility that we do have.  It is the best ttmkfdir there is.  They
all suck, ours just sucks slightly less.

So if you're suggesting we use the original ttmkfdir, or Debians, or
Mandrakes, or $RANDOM_ttmkfdir_version, you're horribly wrong.  I've
personally investigated them all, and every one of them is broken, ours
included.  They just aren't broken in the same places.

At any rate, I don't maintain ttmkfdir, so....


Comment 2 Yu Shao 2002-11-09 07:03:31 UTC
Please download the bug fix code here, also refer to bug id #77272.


What the new fix does is:

* any warning goes to stdout.
* skip any "corrupted" font file and also give warning
* default generate fonts.scale in the current working directory

Comment 3 Michael Lee Yohe 2002-11-09 19:45:31 UTC
mharris: I wasn't implying that Red Hat uses the original utility.  I just
reverted because everytime I ran Red Hat's it would abort :)  I never figured
out the conclusion until I started sleuthing strace's and certain font sets.

Comment 4 Michael Lee Yohe 2002-11-09 19:49:20 UTC
xfs's exclusion is a result of corrupted ttf font stuff produced by ttmkfdir -
sort of.  You can also have a file that generates without a SIGABRT and xfs
STILL ignores the directory (I'm still sleuthing...)  Detecting a corrupt TTF
file is going to be tricky.  This bug is related to Bug 77272, but not entirely.

yshao: I downloaded the ttmkfdir2 tarball, compiled - and ran... 

$ ls -laF ttmkfdir
-rwxr-xr-x    1 myohe    myohe     1053107 Nov  9 13:47 ttmkfdir*
$ ./ttmkfdir


Comment 5 Yu Shao 2002-11-09 22:59:52 UTC
What are there in your current working directory? are you be able to pick up the
corrupted font file for me?

Here is my working example:

[root@localhost TrueType]# pwd
[root@localhost TrueType]# ls -l
total 19612
-rw-r--r--    1 root     root            0 11TB  7 15:05 aaa.ttf
-rw-r--r--    1 root     root        14233 10TB  3 07:10 fonts.cache-1
-rw-r--r--    1 root     root          773 11TB  9 19:59 fonts.dir
-rw-r--r--    1 root     root          773 11TB  9 16:44 fonts.scale
-rw-r--r--    1 root     root      5192076  9TB  2 21:23 gbsn00lp.ttf
-rw-r--r--    1 root     root      4633128  9TB  2 21:23 gkai00mp.ttf
-rw-r--r--    1 root     root     10184696  8TB 16 20:14 zysong.ttf
[root@localhost TrueType]# /root/ttmkfdir2/ttmkfdir
Warning: Can't initialize Face : aaa.ttf(85)

Comment 6 Yu Shao 2002-11-10 03:19:14 UTC
Hi Michael, for the font sewer.ttf you attached in #77491, ttmkfdir will skip it:

[root@localhost ttmkfdir2]# ./ttmkfdir
Warning: Can't initialize Face : sewer.ttf(2)
Warning: Can't initialize Face : aaa.ttf(85)
[root@localhost ttmkfdir2]# ftview ppem sewer.ttf
could not find/open any font file
  error = 0x0002
[root@localhost ttmkfdir2]#

Comment 7 Mike A. Harris 2002-12-19 08:25:51 UTC
Yu, I think you might want to have it print a message stating that the font
is corrupt perhaps.  We might otherwise get a bunch of bug reports stating:
"I installed fonts and ttmkfdir/xfs says can't Initialize Face".

IOW, perhaps make the message more "Your fonts suck" blatant.  ;o)

Just an idea though..  ;o)

Comment 8 Mike A. Harris 2003-10-28 18:56:36 UTC
Presumed to be fixed in RHL 9, rawhide and Fedora Core.

Closing CURRENTRELEASE.  Please reopen if issue persists in Fedora Core 1.

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