Bugzilla – Bug 223591
Different font rendering for various types of programs
Last modified: 2011-04-04 03:19:23 UTC
In openSUSE 10.2, the font rendering is not consistent at all. There are at least 3 different behaviours. KDE programs, GNOME programs and OpenOffice.org all render their fonts (e.g. in the menus) differently. Clearly, OOo looks very different from the rest, but there's also a slight difference between GNOME and KDE programs (which is nevertheless annoying). Maybe every library has a different dpi resolution? I know that this can look much better, Kubuntu is an example where all mentioned programs look the same.
Created attachment 106820 [details] From top to bottom: Firefox, GIMP, Konqueror, OOo Different font rendering for Firefox, GIMP, Konqueror and OOo.
See comment #25 of bug #118131 *** This bug has been marked as a duplicate of bug 118131 ***
I know the bug with OOo - but this report is not only about OOo, but also about Firefox and GTK apps that look different from KDE programs (isn't FF itself a GTK app? Strange that it look different from other GTK programs like GIMP then). It has nothing to do with not being able to change the font hinting! This only applies to OOo, where they allegedly can't do this because it would change the document structure (although I don't agree with this statement). Then at least GTK apps and FF should use the same fonts like KDE apps.
Moreover, bug #118131 is for SUSE 10.0 - I can't add any comments, could someone move it over to openSUSE 10.2?
I moved bug #118131 to openSUSE 10.2.
I cannot reproduce any difference in rendering in the menus between Konqueror and Firefox running on a KDE desktop.
There are no differences by default, but there can be differences after doing something like this: - start kde session - start some kde and some gnome programs and firefox. (they will use the dpi value from the X-server now) - start gnome-font-properties and change the dpi - the changed dpi will be effective in all gnome programs immediately (see comment #13 in bug #193095: "GNOME stores the font options in GConf. Apps call cairo_set_font_options() dynamically when the GConf values get changed from the control center.") - the changed dpi will not be immediately effective neither in firefox nor in the KDE programs. - newly started firefox and KDE programs will see the changes as well because after changing the dpi with gnome-font-properties, the changed will be in the Xft.dpi X-Resource: mfabian@magellan:~$ xrdb -query | grep Xft Xft.antialias: 0 Xft.dpi: 69.000000 Xft.hinting: 1 Xft.hintstyle: hintfull Xft.rgba: none mfabian@magellan:~$ - restart your KDE session. - Now firefox, the KDE programs and all the GNOME programs will use the dpi from the X-server again because KDE sets the following default values for the Xft.* X-resources: mfabian@magellan:~$ xrdb -query | grep Xft Xft.antialias: 1 Xft.hinting: 1 Xft.hintstyle: hintfull Xft.rgba: none mfabian@magellan:~$ (KDE doesn't know that gconf has a changed dpi value) - start gnome-font-properties again: as soon as the gnome-font-properties window pops up the dpi value from gconf is applied to all gnome applications (but not to firefox and the KDE applications).
Similar problems happen for other settings like anti-aliasing for example. If you switch off anti-aliasing in gnome-font-properties, it will immediately have an effect on all Gnome applications, but not on KDE applications. And even restarted KDE applications will not get this change if the anti-alias setting has been saved once with kcontrol. Because saving the anti-alias set to true with kcontrol will insert a rule like <match target="font" > <edit mode="assign" name="antialias" > <bool>true</bool> </edit> </match> into ~/.fonts.conf which takes precedence over the X-resources But Gnome programs will nevertheless use the anti-alias setting from gconf.
This bug is a similar interoperability problem as reported in bug #193095.
This problem is not so easy to solve. Until then you can use the following workaround: Find out what dpi is set in the X-server: mfabian@magellan:~$ xdpyinfo| grep resolution resolution: 98x98 dots per inch mfabian@magellan:~$ If this is not correct, fix the value of DisplaySize in xorg.conf: mfabian@magellan:~$ grep DisplaySize /etc/X11/xorg.conf DisplaySize 430 270 mfabian@magellan:~$ Now set the same dpi in gnome-font-properties. Also make sure that the other settings like anti-aliasing, sub-pixel-hinting, ... are the same in the KDE control centre and in gnome-font-properties.
I think A part of the problem reported here has already been solved by solving bug #217790. If you already have the fix for bug #217790, at least the default dpi should be the same for Gnome and KDE. But as soon as you change it in gnome-font-properties, the problem appears again.
I reassign this bug to federico@ximian.com for the gnome part (I've added mmeeks@novell.com to the CC for the OpenOffice part). And I move this bug to openSUSE 10.3 because we won't fix this for the current release anymore.
*** Bug 64686 has been marked as a duplicate of this bug. ***
It looks like upstream already did part of the work for us: http://mces.blogspot.com/2008/06/online-font-installation.html Gnome-settings-daemon should now be reading ~/.fonts.conf and monitoring it for changes.
This sounds great! I think having all user settings concerning fonthinting in ~/.fonts.conf is the way to go. Gnome, KDE3/4, ... should all observe changes to ~/.fonts.conf and when changing settings with a GUI read in the existing settings from ~/.fonts.conf and preserve the settings which were not changed in the GUI. This way we can get consistent font settings for the different desktops and have changes made in one desktop apply automatically to the other desktops as well.
Ah; the rumour is that Caolan did some work to use Cairo for rendering fonts in OO.o document, such that we re-use all the same desktop hints for OO.o as for the rest of the desktop. Rumour has it that this even doesn't break metrics ;-) Thorsten was looking at getting this into our builds I believe.
Ah, yep, that's in trunk ooo-build since ~a month (coming from m5 upstream). FcConfigSubstitute is used to forward the options to cairo, so it _should_ work now.
It didn't, thx Michael for the hint. Now enabled for OOo trunk.
Does this mean it is in openSUSE 11.0 already?
Is this solved in current versions? (just shaking old bugs during openSUSE Bug Day)
No response. The version with which you had the bug is now obsolete. I'll close this as NORESPONSE. If you can still reproduce it in current 11.4, please reopen the bug and move it to the appropriate version. Thanks!