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 Aborted 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: Always 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:
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.... Reassigning..
Please download the bug fix code here, also refer to bug id #77272. http://people.redhat.com/yshao/ttmkfdir2.20021109.tar.bz2 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
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.
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 Aborted :)
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 /usr/share/fonts/zh_CN/TrueType [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)
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]#
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)
Presumed to be fixed in RHL 9, rawhide and Fedora Core. Closing CURRENTRELEASE. Please reopen if issue persists in Fedora Core 1.