Bug 223591

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!