Xorg fails to load the default CID Type1 and Speedo fonts on a cleanly installed system. Reproducible: Always Steps to Reproduce: 1.setup new gentoo box 2.emerge xorg-x11 3.emerge(wm of choice) 4.configure x 5.startx 6.kill wm session Actual Results: Could not init font path element /usr/share/fonts/Speedo/, removing from list! Could not init font path element /usr/share/fonts/Type1/, removing from list! Could not init font path element /usr/share/fonts/CID/, removing from list! Expected Results: all fonts used to work in xorg original ebuild (6.7.0). Many yahoo users are worried they have a problem with font config files even tho it is showing up on more then one system.
Any chance you've got media-fonts/gnu-gs-fonts-other installed? It tends to break things.
No I sure dont have them installed this problem started just after I emerged xorg then gnome I have seen it occur when removing xfree and switching to xorg but never on a clean install.
Running into this as well. Haven't yet tried purging all traces of xfree and emerging xorg-x11, but from the looks of this the problem may persist anyway...
This is probably a problem with corrupt fonts somewhere. It's a little bit of a painstaking procedure to fix, but see http://www.redhat.com/archives/redhat-list/2003-February/msg02975.html. The error messages are different because that user is using xfs. If you figure out where the problems are, please let me know.
I also ran into this problem, and started a forum topic about it: http://forums.gentoo.org/viewtopic.php?p=1354878 what I see is that the fonts.dir file contains nothing but the character '0' in these directories. I also tried to re-emerge xorg-x11, but the same effect. than I unmerged xorg-x11, deleted the directories in question, and emerged it again - the same effect :( az for the redhat link above, running "ttmkfdir > fonts.scale" in /usr/share/fonts/Type1 for example gives mi a fonts.scale file containing the same '0' character. so it doesn't seem to work. this is very annoying, as the base Monospace font used in Gnome is actually a Speedo font, wihch is not recognized by xorg-x11. what is even stragener is that in the Gnome font selector I can select this font, and see it properly. It seems that Gnome actually sees the font, only xorg-x11 doesn't.
Just a little additional information. The error from the X server is due to an empty fonts.dir file in the affected directories. In each case, the directories contain non-TrueType scalable fonts. The post-install for fonts seems to be clobbering any existing fonts.scale file which is probably not the right thing to do. For Type1 fonts it is simply a matter of running 'mkfontscale' in the directory and then rebuild the fonts.dir file with mkfontdir. Another problem is that I can't find a utility to create the fonts.scale file for Speedo fonts. I've just been copying the Speedo/fonts.scale file from an old RH install when it gets clobbered.
Lynn: So doing what you described fixes the errors encountered?
Confirmed this. Will look into replacing ttmkfdir calls w/ mkfontscale for Type1 fonts. Don't have a solution for Speedo/CID yet. BTW, the likely reason GNOME sees the font but X doesn't seem to is that GNOME uses the client-side font setup (xft/fontconfig/freetype) rather than the core font one.
Here's some code from Fedora's xfs init script, for comparison: if ls | grep -iqs '\.tt[cf]$' ; then # TrueType fonts found, generate fonts.scale and fonts.dir ttmkfdir -d . -o fonts.scale && mkfontdir . &>/dev/null fi if ls | grep -iqs '\.ot[cf]$' ; then # Opentype fonts found, generate fonts.scale and fonts.dir mkfontscale . && mkfontdir . &>/dev/null fi if ls |grep -Eiqsv '(^fonts\.(scale|alias|cache.*)$|.+(\.[ot]t[cf]| dir)$)' ; then # This directory contains non-TrueType/non-Opentype fonts mkfontdir . &>/dev/null fi
This should be fixed in xfree-4.3.0-r{5,6} and xorg-x11-6.7.0-r{1,2} as of about 5 minutes ago in CVS. It should show up on rsync servers within an hour or so. Remerging X and running etc-update is probably the easiest way to remedy any problems. I won't elaborate on the others, because I don't have the time right now.
*** Bug 59367 has been marked as a duplicate of this bug. ***
