Bugzilla – Bug 193095
Font of Gnome apps don't have antialiasing in KDE
Last modified: 2009-07-29 14:02:07 UTC
I'll attach screenshots
Created attachment 93761 [details] Compare fonts in Gnome apps to fonts in KDE apps Fonts in Gnome apps don't have anti-aliasing
Federico, did something change? (note that this is alpha2)
(In reply to comment #2) > Federico, did something change? (note that this is alpha2) Huh, not that I know of. Have changes been made to Pango or Fontconfig? The old bug relative to font options is bug #104365.
Really obvious and ugly.
fail to see how it is a KDE bug if GNOME apps are not reading the session settings correctly
Silviu, can you try http://primates.ximian.com/~danw/cairo-1.2.2-10.i586.rpm and see if that fixes the bug for you? (That package reenables the cairo patch from 104365, which had gotten disabled because it didn't apply cleanly to cairo 1.2.2.)
I have x86_64...
ok, try http://primates.ximian.com/~danw/cairo-1.2.2-10.x86_64.rpm then.
No change; maybe I need cairo-32bit too? rpm -qa | grep cairo cairo-1.2.2-10 cairo-32bit-1.2.2-9 libsvg-cairo-0.1.6-22 python-cairo-1.2.2-3
Created attachment 101523 [details] no font aa
ok... there must be some other change needed as well. i don't really know much about cairo and our fontconfig setup
This is not a bug; it's just missing interop between KDE and GNOME in the way they configure font rendering options and in the way they propagate changes about those options. GNOME stores the font options in GConf. Apps call cairo_set_font_options() dynamically when the GConf values get changed from the control center. As far as I know, KDE stores ~/.fonts.conf (or ~/.fontconfig; I don't remember) when things get changed in its control center, and apps need to be restarted to get the new options. We need a single way to store things and propagate changes. It's easy enough for GNOME to monitor changes to ~/.fonts.conf. There may be some missing APIs in Fontconfig to change the configuration dynamically, but that shouldn't be a problem to add, either. There remains the problem of remote X clients. GNOME propagates its font settings using the XSettings protocol, and also sets X resources for apps which may wish to use them (though I don't know of any apps that do).
I don't this has much to do with monitoring changes to ~/.fonts.conf or the X resource (which KDE sets as well and which Xft reads by default if I'm not mistaken, so even remote X clients should work). If that was the case, it'd be enough for the reporter to restart and the problem would be gone (in fact the KDE dialog even simply says that apps have to be restarted). If KDE apps get antialiasing, GNOME apps should get it as well from that setting, unless they exclusively use the gconf setting and that one defaults to false (or whatever, I don't know how exactly reading this setting works in GNOME), so this looks like GNOME problem to me.
Bug went away from beta1.
(In reply to comment #15) > Bug went away from beta1. I (still/again?) see it on Factory from monday morning (somewhat newer than beta1) with a fresh test user :-( (tested with GIMP) In case it's relevant: I updated from 10.1 final.
I have been seeing this for serveral weeks now. I use current factory: # rpm -qv cairo freetype fontconfig cairo-1.2.4-2 freetype-1.3.1-1187 fontconfig-2.4.1-9
I had similar problem when i removed gtk-qt-engine package.
Still in Beta 2.
*** Bug 214280 has been marked as a duplicate of this bug. ***
Some additional info in the dupe.
Lubos Lunak> X resource (which KDE sets as well No, KDE doesn't set this. None of the Xft.* resources is set in a KDE session. They get set though as soon as gnome-font-properties has been started once.
i just ran gnome-theme-manager as was said in 214280. This crashed firefox and thunderbird. But now all font problems are gone! So just starting gnome-theme-manager and exiting it without doing anything solves this problem.
gnome-theme-manager probably sets the Xft.* X-resources, just like gnome-font-properties does. But this will help only until you restart your KDE session.
$ xrdb -query | grep Xft Xft.antialias: 0 Xft.hinting : 1 Xft.hintstyle: hintfull It looks like we have a problem with default settings or something.
New kdebase3-SuSE package submitted.
.
Can you please explain what you did to fix the problem? How are the Xresources set now?
I changed the default config file to use the right config key name (it was either named incorrectly or it has changed over the time without the SUSE config file having been updated). So now it's "Xft.antialias: 1" and that's all, no other change.
... but we still don't have a compatible way to store and use the font configuration from both desktops.
But this bugreport is about GNOME apps not having antialiasing in KDE. Compatible font config is neither this problem nor critical, if you want something done about it please open a Fate issue or something.
It is not only anti-alias that is not used, but it seems that OO does no longer care to use the bytecode-interpreter for ttf, as it did in 10.1. I have aa disabled and set OO to use "system fonts" for GUI. But not only for the GUI ttf are not rendered by the bytecode interpreter as it seems. See attached screenshot and bug 226217.
Created attachment 108455 [details] font rendering in OO
If bug 214280 really is a duplicate of this one it has to be re-opened, since it is not fixed in the GM.
Your attachment in comment #33 is in jpeg format. Please don't attach screen shot in jpeg format because jpeg compression is not lossless. Artifacts of the jpeg compression make it impossible to see small details like font rendering correctly. Please use a lossless format like .png instead.
Although you are right about lossless you must be kidding if you do not see the difference between the text in the OO window and the text in the KDE window. Or are you suggesting that while in the OO window there are fragments those misteriously are absent in the rest of the picture?
Anyway, please attach it as a .png as well.
Created attachment 108508 [details] font rendering in OO
Thank you.
OK, this OpenOffice rendering problem has nothing to do with "Fonts of Gnome apps don't have antialiasing in KDE", OpenOffice is a special case. Therefore there is no need to REOPEN this bug. Let's continue to investigate the OpenOffice problem in bug #217704.