From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
When I select anti-aliased fonts in KDE, all fonts change to a script font
that is unreadable. Also, the choices of fonts in the font menu is
reduced drastically. (no helvetica for example)
Steps to Reproduce:
1.Enter KDE control panel
2.Select anti-aliased fonts
3.restart X server
Actual Results: All fonts are antialiased, but have been changed to
script. Many font choices are missing from the font menue.
Expected Results: Font choices should remain the same as they were before
antialiasing was turned on (this is what happened in the wolverine beta)
Could it be that only certain types of fonts can be anti-aliased now?
Regardless, the font setup of these distributions needs work...appearance
of web pages are frequently terrible micro-sized type compared to
Windows. Fixing this would make the system more attractive to beginners
who don't know how to hack the system to improve it.
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
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"
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
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
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
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
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.
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
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
I've done nothing to the xfs config file that would result in fewer fonts being
*** 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:
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