Issue 59127 - OO window font does not 100% match gtk font
Summary: OO window font does not 100% match gtk font
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0
Hardware: PC Unix, all
: P4 Trivial with 2 votes (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2005-12-09 12:40 UTC by mini
Modified: 2017-05-20 11:29 UTC (History)
6 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

Example of bold fonts (22.42 KB, image/png)
2005-12-12 13:19 UTC, mini
no flags Details
additional patch to that of issue 64508 to honour the cairo subpixel settings (9.84 KB, patch)
2006-08-15 10:53 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description mini 2005-12-09 12:40:17 UTC
I'm using OO from Debian unstable. 

When using openoffice, the interface fonts are not
always 100% the same as those used by gnome. Openoffice follows
my selections in the gnome preferences, but there is a slight
mismatch in appearance.

For example, if choosing Verdana from the msttcorefonts package,
I get the following:

The top bar is the GNOME window list, and then you see the OO meny bar.

Is this behaviour expected for some reason? Is there a way around it?

Comment 1 carsten.driesner 2005-12-09 15:46:36 UTC
cd: Changed component to gsl as framework doesn't set/change the window title
font. Set hdu on CC to have his opinion.
Comment 2 2005-12-09 16:08:44 UTC
> Is this behaviour expected for some reason?

OOo enables (auto-)hinting to avoid the gray cloud around the letters like in
the windows list in the screenshot. Magnify the screenshot to see the difference.
Comment 3 mini 2005-12-09 16:27:05 UTC
hdu: Yes that might be it. So OO does this differently from GTK? Don't they both
use freetype/fontconfig? I can't see why they behave differently... or if it's
deliberate, why that is supposed to be good. This hurts desktop integration, IMHO.

In my /etc/fonts/conf.d/autohint.conf:

  <match target="font">
    <edit name="autohint" mode="assign"><bool>true</bool></edit>

So it seems autohinting should be on for all apps?

I'm still not sure what is really going on, or why. Is this really a GNOME/GTK+
bug, then?

Comment 4 mini 2005-12-12 13:19:38 UTC
Created attachment 32304 [details]
Example of bold fonts
Comment 5 mini 2005-12-12 13:21:02 UTC
The difference is even more marked when using bold fonts. See the attachment...

Can this still be attributed to auto-hinting?
Comment 6 2005-12-14 11:40:55 UTC
The gray smear around the GTK widget font in the first screenshot indicates that
no hinting whatsoever is enabled. In the second screenshot the smear is not
visible though. Maybe the difference is that OOo prefers "light hinting". OOo
doesn't use xft yet (issue ???).
Comment 7 mini 2005-12-14 13:09:37 UTC
I have now carefully reviewed my fontconfig configuration. It seems I had
misunderstood it due to a recent configuration methodology change I was unaware
of. My bad...

Re-enabling hinting (native) makes the GTK apps start looking 100% like OO. 

So the question remains - why does OO not follow system font settings (including
hinting) *even when explicitly told so* in Tools->Options->General->View? Is
that because it's not using xft?

Is there an issue for that? In that case I'd happily let you close this issue.
Otherwise, I'd accept changing the subject of this issue or file a new one for
that problem, which I still think hurts usability.


Comment 8 thorsten.martens 2005-12-21 10:40:31 UTC
TM->SBA: Please have a look. Don´t know, who has to have a look at font problems
because US has left the team.
Comment 9 Olaf Felka 2006-03-16 14:29:01 UTC
reassigned for further investigations
Comment 10 mini 2006-03-16 14:41:54 UTC
By the way, I think I have seen the same issue with Java 1.6, with the native LaF.

Comment 11 caolanm 2006-08-15 10:52:41 UTC
This may be dependant on issue 64508, with probably requiring this additional patch
Comment 12 caolanm 2006-08-15 10:53:44 UTC
Created attachment 38523 [details]
additional patch to that of issue 64508 to honour the cairo subpixel settings
Comment 13 stefan.baltzer 2006-08-18 11:25:42 UTC
SBA->HDU: Please proceed.
Comment 14 stefan.baltzer 2006-08-18 11:30:26 UTC
SBA->CMC: Thanks. I change the isue type to "patch" now.
Comment 15 mkretzschmar 2006-10-11 13:56:26 UTC
The patch adds a dependency on gtk+ 2.10+ because of gdk_screen_get_font_options.

Would it be possible to get the same information directly from the xsettings
(cf. gtk+/gtk/gtksettings.c) without using a cairo data type?
Comment 16 philipp.lohmann 2006-10-11 15:21:16 UTC
I too think doing without the link dependency on gtk 2.10 would be better if
Comment 17 2006-11-02 13:08:10 UTC
Looking over this issue again the situation looks like this:
- we didn't have artificial bold then
  => the original problem of this issue is solved nowadays
- the gtk integration only gives a coarse approximation of the system font
settings (e.g. only four levels of fontweight instead of all possible values)
  => I'd like to address this subissue of the original problem in this issue number
- vcl-ft integration didn't use the exact same hinting options as native gtk.
This issue got addressed by Caolan's patch but it would introduce unwanted
dependencies and wouldn't solve the original problem shown in the screenshot.
I'd like to split this issue off this one here. Any volunteers who'd like to
rework the patch to get rid of the unwanted dependency?
Comment 18 2006-11-02 13:11:16 UTC
Oops, I saw that I referred to the only screenshot here instead of the one with
the missing link in the original problem.
Comment 19 2007-01-11 10:27:33 UTC
Retargeting (the problem with the new dependency mentioned by PL has to be
resolved first)
Comment 20 Martin Hollmichel 2008-01-28 02:31:26 UTC
set target 3.x
Comment 21 Marcus 2017-05-20 11:29:55 UTC
Reset assigne to the default "".