Apache OpenOffice (AOO) Bugzilla – Issue 59127
OO window font does not 100% match gtk font
Last modified: 2017-05-20 11:29:55 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: http://kmr.nada.kth.se/~mini/oo.png 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? /Mikael
cd: Changed component to gsl as framework doesn't set/change the window title font. Set hdu on CC to have his opinion.
> 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.
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> </match> 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? /Mikael
Created attachment 32304 [details] Example of bold fonts
The difference is even more marked when using bold fonts. See the attachment... Can this still be attributed to auto-hinting?
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 ???).
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. Thanks, Mikael
TM->SBA: Please have a look. Don´t know, who has to have a look at font problems because US has left the team.
reassigned for further investigations
By the way, I think I have seen the same issue with Java 1.6, with the native LaF. /Mikael
This may be dependant on issue 64508, with probably requiring this additional patch
Created attachment 38523 [details] additional patch to that of issue 64508 to honour the cairo subpixel settings
SBA->HDU: Please proceed.
SBA->CMC: Thanks. I change the isue type to "patch" now.
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?
I too think doing without the link dependency on gtk 2.10 would be better if possible.
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?
Oops, I saw that I referred to the only screenshot here instead of the one with the missing link in the original problem.
Retargeting (the problem with the new dependency mentioned by PL has to be resolved first)
set target 3.x
Reset assigne to the default "issues@openoffice.apache.org".