From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
The fonts in Qt and KDE apps are not antialiased anymore.
In GNOME/GTK fonts are alright.
All configurations for Qt related to Xft are set.
I attach an strace of qtconfig3.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Login in GNOME desktop (through gdm).
Start qtconfig3 or any other Qt or KDE app.
Created attachment 95778 [details]
strace of qtconfig3
Hm, it looks like that useXft is disable in your config file.
Please start "kcmshell fonts" and check if "Use anti-aliasing for
fonts" is on
Could you please send your $HOME/.qt/qtrc.
Created attachment 95790 [details]
Seems alright. Notice, that delete .qt and .kde to restart
cleanly. I also checked the settings in kcontrol and qtconfig3.
Strange, strange. I started qtconfig3 remotely via ssh from an
RH9 box. Now fonts are antialiased, although a bit small.
Maybe related to this:
On both machines with the same NVIDIA driver 4496,
on running glxgears, on FC1 I get a
Xlib: extension "XFree86-DRI" missing on display ":0.0".
on RH9, I don't.
The NVIDIA driver doesn't need dri, and on both machines
Load "dri" is commented out. So far all OpenGL apps work
as expected on FC1, so this warning seems to be harmless.
Perhaps I will open a separate bug for this.
It looks like the same problem as in bug #108672 is at work.
I switched to TwinView instead of Xinerama, and the fonts
in Qt and KDE display anti-aliased.
Unfortunately TwinView has its own issues.
Just to confirm the problem
Same machine, Red Hat 9 and FC1, using same XF86Config.
RH9 with Xinerama has true type fonts everywhere.
FC1 with Xinerama enabled does not have truetype fonts in KDE/qt apps.
Disabling xinerama restores truetype-ness.
Same problem with dual monitors. No anti-aliasing with xinerama, nice
fonts with TwinView.
I have also run into this problem using a radeon 7500 and xinerama.
The on bit of info I have to add is that I upgraded the qt in redhat 9
to 3.1.2-14 quite some time before Fedora Core came out and the fonts
were fine in qt apps with xinerama enabled. I also play with a DTP
app called scribus that is qt based, and it will sometimes hang on
start related to fonts. It does not ever hang when xinerama is disabled.
could you please try to install XFree86-4.3.0-2 from RHL9 in Fedora
Core. Does this problem still appear?
I installed but of X from RHL9 and this was the outcome. I first
downgraded only the Xfree86 rpm with no change in behavior. I then
downgraded XFree86-libs XFree86-libs-data and XFree86-xfs. I then
restarted X and the problem was gone. Qt apps looked great and all
was well. I then upgraded back to the stock Fedora rpms for XFree86,
-libs, and -libs-data, and the problem returned. I then upgraded
XFree86-xfs to the stock Fedora so I would be back in sink with a
stock Fedora install.
I can confirm that downgrading to XFree86-libs-4.3.0-2 from RedHat 9
fixes the problem.
I installed the RPM while being logged into my (ugly-looking) KDE
session, then ctrl-alt-backspace and logged in again. Problem is gone.
*** Bug 110497 has been marked as a duplicate of this bug. ***
Please see bug 110497 and note:
I've tried the new XFree86-libs but with the old libXrender library
and that fixes the problem.
If I put libXrender.so.1.2 back in all works OK
If I put libXrender.so.1.2.2 in it breaks ....
Just looked at source RPMs for new RH90 Xlib packages and note that Xrender/render
was upgraded to 0.8.3 - I suspect a prime candidate for the introducing/exposing the
I don't know the insides of X well enough to work out the problem on my own but am
more than happy to provide any debug logs required.
This may be related - found this on Mandrake .....
Confirmed - Xrender.c 1.18 fixes the problem.
Make Xrender depth checks work with broken Xinerama code
I believe this bug is now present in Redhat 9 after the recent update
of X packages published through RHN (RHSA-2003:288).
ok it seems a problem in XFree86
*** Bug 107473 has been marked as a duplicate of this bug. ***
libXrender 0.8.4 has been released, which appears to contain a
fix for this problem. I'm upgrading to it currently for Fedora
Fixed in XFree86-4.3.0-58
As bug 110487 is marked as a duplicate of this bug for RH9.
I notice that a new version of XFree86 has come out for RH9
(XFree86-4.3.0-2.90.55) for which this bug is still not fixed. Is the
suggested fix for RH9 to get the lastest fedora development package?
As an additional note for Red Hat Enterprise Linux customers who may
experience this problem as well, as noted above for Red Hat Linux 9,
the current fix for this is considered experimental only for now and
not yet tested and production stable.
Since we release quarterly updates for RHEL 3, if the new Xft library
is considered to be stable in time for the next RHEL 3 quarterly
update, this fix may get included. Otherwise it will likely wait
until the next quarterly update.
The important thing is that the fixes are widely tested before
being included in any official OS updates for RHEL 3 and/or RHL9
and/or Fedora Core 1.
Hope that helps clarify things a bit.