Bug 37494
Description
Greg Corson
2001-04-25 02:15:52 UTC
This is not technically a bug. The problem is that the standard fonts (Helvetica etc.) are bitmapped fonts, meaning they can't be antialiased. The Xrender extension therefore takes a different font; since it has no way of knowing what the font is supposed to look like, it picks the (alphabetically) first font that matches the other parameters (which is really just proportional vs. monospaced), which happens to be Arioso (a script font) on fairly standard systems. The obvious fix would be to hardcode a list of standard fonts and a list of possible replacements into Xrender; not very nice, but effective (assigning to XFree86 for this purpose). An alternative fix would be to use scalable fonts even in non-anti-aliased mode, but this would slow things down. Workaround: Turn on anti-aliasing and switch to a resolution where the font is readable. Open KControl, go to Look and Feel -> Fonts and pick other fonts. Just two things that are rather odd.... 1. This wasn't a problem with Wolverine Beta, it worked fine. 2. Someone else in the office did a workstation install on a desktop PC (mine is a laptop) and it seems to have the full font list available when doing anti- aliased fonts. The only differences between their system and mine are a slightly higher res monitor and he is using KDE by default while I'm choosing it from the gnome "session" menu on the login screen. Could there be some difference in the way the font server was configured this time around? He did do a workstation while I did a custom install and checked ALL the packages. Both installs were from the same disk set/version (seawolf) Created attachment 16667 [details]
output of chkfontpath from system where anti-aliasing works ok
Created attachment 16668 [details]
Output of checkfontpath from system with broken anti-aliasing
Created attachment 16669 [details]
output from chkfontpath -l on system with working anti-alising
Created attachment 16670 [details]
Output of chkfontpath -l on system with broken anti-aliasing
See the previous attachments for samples of the font server configuration on a system where anti-aliasing seems to work, and on one where it doesn't. I'm wondering if the font server on the broken system might have so many bitmap versions of each font that it always returns a bitmap version, even if a scaleable one exists too...tricking KDE into thinking there isn't a scaleable version to use for anti-aliasing. For example, there are 477 "helvetica" fonts listed on the broken system and only 120 on the working one. The other strange thing is that when anti-aliasing is turned on the "broken" system shows a number of font names that don't show up at all on the output of chkfontpath, on the font picker of the working system or on the font picker of the broken system when anti-aliasing is off. These font names include "Arioso", "Chevara" and "Conga" Any ideas? Ok, I have spent some time examining the system configuration as created by both a workstation install and an "everything" install. I think I have located the problem, or at least the reason why it is so confusing. Out of the box it looks like X is configured NOT to use freetype, Type1 or TrueType fonts even though some are in the xfs font path. The xft (freetype) module which has a different font list than xfs, which includes a number of Truetype fonts. I'm no expert, but from experimenting with how things work, it appears that when in KDE anti-aliased mode, you get only the truetype fonts from paths in the xft config file. Since X has not been configured to support Type1, TrueType or Freetype, when you turn anti-aliasing OFF, none of the TrueType fonts are available. This seems to account for why aliased and anti-aliased modes create totally different font lists with no fonts in common. It would greatly reduce confusion if, at minimum, the installer configured X to use TrueType AND configured both xft and xfs to have the same set of TrueType fonts in their paths. At least this way, when someone switches on anti-aliasing they would only see their list of available fonts shrink, rather than see it completely change. The other problem that is probably fixable is getting all script fonts when you switch to anti-aliasing the first time. If, like you said, the font engine is hunting for something similar to helvetica and can't find it, so it picks Arioso, wouldn't it be possible to specify the default font types a bit more completely so it will find a more readable font? For example, can you specify a non-serif'ed font? A related problem seems to be that there is no TrueType font in the current distribution that matches what KDE wants as a "fixed" font (the second choice down in the KDE "Fonts" panel) so even if you manually set it to a readable font, it keeps jumping back to Arioso on it's own. The easiest fix, I suppose, would be to supply a "helvetica" and a "fixed" TrueType font. Failing that, there seems to be a lot of substitution/aliasing stuff in the font servers, couldn't some kind of alias be installed so the system would pick a more readable font than Arioso when it failed to find a match for the helvetica it wants? If possible, please confirm if it sounds like I'm write about how X and your xfs & xft servers are configured. After I've reved the config files to produce a better presentation, I'd be happy to send you the changes Did some more work, installed some of the Windows TrueType fonts and finally discovered what the problem was with the fonts in /usr/share/fonts/default/TrueType (Arioso, Chevera...etc.) It appears these fonts did not have a correctly built fonts.dir file (it was empty) after rebuilding this, they show up properly in both aliased and anti-aliased modes. So ACTUAL BUGS 1. /usr/share/fonts/default/TrueType (part of an "everything" custom install) needs to have the fonts.dir and fonts.scale rebuilt. As shipped, they only work with the xft font rendering stuff in anti-aliased mode and won't appear under xfs. 2. The "fixed width" font in the KDE font picker module is unable to find any font it likes when in anti-aliased mode. The list of available fonts contains only "fixed" which looks ok but if you choose it, it will revert to the first truetype font on the list every time you logon. ISSUES 1. You should have a mini faq/HOWTO that describes how your font server (xfs and xft) are setup, it took me some time to figure out that one was serving aliased truetype and the other anti-aliased truetype. None of the on-line howto's gave a good description of how this was setup. 2. You should attempt to supply fonts or font aliases so that when someone switches into anti-aliased kde the first time, they get a readable configuration. If you can confirm that what I've found is correct before closing this bug, I'd appreciate it. *** Bug 39628 has been marked as a duplicate of this bug. *** I've tried the fix in bug 39628 which seems to work in anti-aliased mode. However when I switch back to normal mode, now pressing the "choose" button for the "fixed" font results in xfs crashing. This is on a freshly installed machine. Prior to using anti-aliased mode and switching back to normal mode the font picker used to return a whole list of fonts for this choice. I've done nothing to the xfs config file that would result in fewer fonts being available. *** Bug 40329 has been marked as a duplicate of this bug. *** Created attachment 18391 [details]
my workaround for this problem, also in Mandrake 8.0
Any chance of a binary version of this patch? I'd prefer not to have to go through the exercise of building kdelibs from source if possible. I've built a new kdelibs incorporating the patch provided here. It's available from my website: http://www.math.unl.edu/~rdieter/Software/Linux/kde/ Enjoy. Bero, is this problem still present in rawhide with Xft2/fontconfig? If so, we should try to resolve it. I haven't had any reports of it happening now for ages, so I assume it is no longer a problem in RHL 7.3 and later. This problem hasn't occured for a while now. It definitely isn't present in rawhide currently, and our final release of our new OS once released shouldn't show this problem either. Closing as RAWHIDE |