Description of problem: Between FC2 and FC3 (xorg-x11 versions 6.7.0 and 6.8.1) /usr/X11R6/%{_lib}/modules/fonts/libspeedo.a module vanished. Font files in /usr/X11R6/lib/X11/fonts/Speedo are still there but there are not accessible to a font server; and I have really good uses for these "black" fonts from there which otherwise are not available. The other font support module which disappeared on the same transition is /usr/X11R6/%{_lib}/modules/fonts/libxtt.a but its functionality is probably covered by libfreetype.a or it is not?
I will need to do a bit of upstream investigation to be 100% certain, but if I'm not mistaken, the freetype library handles speedo fonts now, and libspeedo was removed upstream due to that. Of course you would need to have a version of freetype installed that handles the speedo fonts for it to still work. Again, this is just a vague recollection, and not authoritative, but I'll find out for sure and update the report. The libxtt.a module is missing because XTT was obsoleted and removed from X.Org after freetype acquired the main features that XTT had been included for - mainly for special uses in the Asia region (TTCap). Freetype now includes most or all of the features that XTT provided in previous releases. Our upgrade procedure should munge the config file to remove reference to non-existant modules however, so this shouldn't pose a problem for anyone.
I'm not aware of any support for the incredibly ancient speedo format in FreeType .... Bitstream's newer 'pfr' format is supported. I consider the correct resolution here is to remove /usr/X11R6/lib/X11/fonts/Speedo from the font packages. While clearly there will always be people who really like one font or another, we ship a pretty comprehensive range of Latin fonts without the fonts in Speedo format.
> if I'm not mistaken, the freetype library handles speedo fonts ... Maybe this is not that version of 'freetype' module? I do have 'Load "freetype"' in xorg.conf but this does not seem to help. xfd -fn '-*-*-black-*-*-*-*-*-*-*-*-*-*-*' should be good enough for a test case as these "black" fonts seem to be available only in a speedo format (at least on a "standard" installation without fonts from extra sources). 'chkfontpath' does list '/usr/X11R6/lib/X11/fonts/Speedo' among others. I do not have at this moment FC3 installation on x86, as opposed to x86_64, handy to check that there but I have such with "rawhide" packages. The above 'xfd' command ends up there too with "Cannot convert string ..." and "no font to display". No problems with version 6.7.0 of xorg-x11. I would not mind dropping support of the format if fonts would be available in some other format or at least if it would be possible to find some tools to convert.
Just in case you think that almost nobody cares about these speedo fonts, I thought I'd pipe up and say I miss them, too. I just spent an hour figuring out why my window manager's menus all switched to "fixed" when I upgraded to fc3. I'd been using the -bitstream-courier-* fonts, which I hadn't even realized were speedo fonts. I'd just picked them because they looked good at the size I needed them.
Support for speedo fonts depends on wether X.Org supports them still or not. That still has not been confirmed, however I've made a few attempts now to get a solid answer. Still waiting. If X.Org does not support speedo fonts any more, then they are simply not supported. You'd have to file a feature request to X.Org to change that if it is the case. I'll update the report again if I am able to determine wether they should still work or not.
Ok, I have tracked this problem down and have some solid information to pass on now. X.Org intentionally removed Speedo font support because it is very old and nobody produces these fonts anymore. Unfortunately, they neglected to also remove the fonts, so they still get installed. https://bugs.freedesktop.org/show_bug.cgi?id=548 I have inquired on xorg about the rationale for the decision, and am awaiting responses. There are two possible solutions which X.Org will theoretically take: 1) Re-enable speedo font support. or 2) Remove the speedo fonts too. Whichever they decide, we will probably follow their decision for maintenance consistency. I'll update the report once someone upstream responds.
Additionally, it seems that I was incorrect about freetype supporting speedo. I just wanted to state that also, to avoid confusion.
*** Bug 154191 has been marked as a duplicate of this bug. ***
Ok, speedo fonts have been disabled in xorg-x11 packaging now, and I've regenerated the fonts-xorg tarball and updated it to 6.8.2. New fonts-xorg-6.8.2 is in rawhide now and no longer provides the *.spd speedo fonts. The font directory has been removed now and also removed from xfs configuration. Upstream X.Org has indicated that they might convert the existing *.spd fonts into Type1 or TTF files in the future. If that happens, they'll be in a future Xorg release. I'd set the status of this to "RAWHIDE" as I've updated the packages to remove the fonts, however the initial report indicates that you want to use these fonts still, and Xorg no longer supports this font format, so setting status to "WONTFIX" instead, although I guess it's just semantics... On a closing note.. If upstream converts the .spd fonts to Type1 or TTF, feel free to file a new bug report to RFE inclusion of the converted fonts and we'll consider including them in a future update. Thanks.
From User-Agent: XML-RPC xorg-x11-6.8.2-1.FC3.45 has been pushed for FC3, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
> xorg-x11-6.8.2-1.FC3.45 has been pushed for FC3, which should resolve this issue I am not sure what this resolution in that particular release should be as opposed to earlier updates. Do you mean that conversions suggested in comment #11 did happen? Fonts are supplied in various 'fonts-...' packages anyway and these were not updated right now. Otherwise /usr/X11R6/lib/X11/fonts/Speedo and various, currently useless, .spd files are absent already for quite a while.