[ooo-build] OpenOffice.org subpixel font rendering broken with new cairo

Thank you for taking the time to report this bug and help make Ubuntu better, we are aware of this issue, and we believe it should be fixed when the first beta comes out, if you could let us know what happens when the beta comes out that would be fantastic.

My apologies, while I was investigating this bug I happened to be investigating a second bug and got them mixed up, please ignore my previous comment but rest assured I am investigating this bug.

Thanks for reporting this bug and helping make Ubuntu better, can you update to the latest set of patches and let me know if the problem still persists?

Yes, problem is still exists, nothing was improved.

2008/10/1 Neil Munro <email address hidden>

> Thanks for reporting this bug and helping make Ubuntu better, can you
> update to the latest set of patches and let me know if the problem still
> persists?
>
> ** Changed in: openoffice.org (Ubuntu)
> Status: New => Incomplete
>
> --
> Open Office font rendering
> https://bugs.launchpad.net/bugs/271283
> You received this bug notification because you are a direct subscriber
> of the bug.
>

These are two examples of one document, made in the OO.org and in the google
docs:

2008/10/1 Я <email address hidden>

> Yes, problem is still exists, nothing was improved.
>
> 2008/10/1 Neil Munro <email address hidden>
>
> Thanks for reporting this bug and helping make Ubuntu better, can you
>> update to the latest set of patches and let me know if the problem still
>> persists?
>>
>> ** Changed in: openoffice.org (Ubuntu)
>> Status: New => Incomplete
>>
>> --
>> Open Office font rendering
>> https://bugs.launchpad.net/bugs/271283
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>

Ubuntu Intrepid Ibex has been released and this bug is still present. Please hurry and fix it, fonts are just ugly, I can't stand them! :(

Confirming. Fonts in Firefox and elsewhere look great; fonts in OpenOffice (both 2.0 and 3.0) look terrible. Please fix.

Here's an attachment showing the yellowish blur that fonts get in OpenOffice (both 2.0 and 3.0) with subpixel font rendering turned on. No other app shows this blur--not Firefox, not any other app.

In Hardy, subpixel font rendering in OpenOffice was fine.

Maybe I should say "yellowish-reddish" or even "rainbowish." Anyway, it's annoying as heck and makes it impossible to work on documents for long periods of time.

Found a fix:
- Quit OpenOffice (exit quickstarter)
- In Appearance>Fonts>Rendering, change to subpixel with full hinting and RGB
- Restart OpenOffice, rainbow artifacts are gone.

It's not a fix. I need "subpixel with slight hinting, which I set up in
System->Preferences->Appearance->Font->Details
But I have something similar to GrayScale with no hinting:

2008/11/14 ddumanis <email address hidden>

> Found a fix:
> - Quit OpenOffice (exit quickstarter)
> - In Appearance>Fonts>Rendering, change to subpixel with full hinting and
> RGB
> - Restart OpenOffice, rainbow artifacts are gone.
>
> --
> OpenOffice.org subpixel font rendering broken with new cairo
> https://bugs.launchpad.net/bugs/271283
> You received this bug notification because you are a direct subscriber
> of the bug.
>

A quick & dirty workaround at least for x86 and for now is to use cairo and pango from hardy-updates. I apologize for misusing this bug for a sort of a howto:

1. Download the packages from

http://packages.ubuntu.com/en/hardy-updates/libcairo2
http://packages.ubuntu.com/en/hardy-updates/libpango1.0-0

2. Unpack them

dpkg -x libcairo2_1.6.0-0ubuntu2_i386.deb .
dpkg -x libpango1.0-0_1.20.5-0ubuntu1_i386.deb .

3. Copy the content of the resulting usr/lib/ directory somewhere where ld.so won't find it, like

sudo cp -r usr/lib /opt/

4. Load libpangocairo-1.0.so.0 and libcairo.so.2 prior to running ooffice, maybe by placing something like

#!/bin/bash
LD_PRELOAD=/opt/lib/libpangocairo-1.0.so.0:/opt/lib/libcairo.so.2 \
/usr/bin/ooffice $1 $2
exit 0

as /usr/local/bin/ooffice and making it executable (please replace this wrapper with a better one).

It is required to load libpangocairo prior to libcairo, otherwise OpenOffice.org will crash opening the GTK filepicker. I haven't tested with the amd64 Intrepid.

@Ilja Sekler - Thank you so much for this I thought I was gonna have another 6 months of awful fonts.

You can change the openoffice quickstarter to load the script above with /usr/bin/ooffice -quickstart -nologo -nodefault $1 $2 instead of just /usr/bin/ooffice $1 $2.

Yes this is a great workaround. The easiest way however to wrap this command like this:

1. Follow steps 1 to 3 made by Ilja Sekler

2. cd /usr/lib/openoffice/program

3. sudo mv soffice soffice.real

4. sudo gedit soffice

5. paste:
#!/bin/bash
LD_PRELOAD=/opt/lib/libpangocairo-1.0.so.0:/opt/lib/libcairo.so.2 \
/usr/lib/openoffice/program/soffice.real "$@"

Here you go.

Do you still see this problem on Ubuntu Jaunty (9.04)?

Thanks,

Chris Cheney

Yes, this problem is still here.

2009/2/4 Chris Cheney <email address hidden>

> Do you still see this problem on Ubuntu Jaunty (9.04)?
>
> Thanks,
>
> Chris Cheney
>
> ** Changed in: openoffice.org (Ubuntu)
> Status: Triaged => Incomplete
>
> --
> [ooo-build] OpenOffice.org subpixel font rendering broken with new cairo
> https://bugs.launchpad.net/bugs/271283
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Yep still there. I dont use workarounds. I'd rather wait for the official bug fix.

Hi folks,

I ran into this issue with OpenOffice.org 3 on Debian unstable (I use a port of the Ubuntu cairo/xft lcd filter patches). I looked into it a bit, and there seems to be two underlying problems that, if either of them were solved, would fix the issue:

1. OpenOffice.org doesn't pay attention to the "lcdfilter" option in fontconfig (/etc/fonts/fonts.conf, ~/.fonts.conf, etc.). Instead, it appears to rely on the Xrm database configuration (Xft.lcdfilter) for that (and other?) antialiasing option.

2. The GNOME Font preferences (gnome-settings-daemon?) doesn't support setting the lcdfilter option.

I believe the way things work is that gnome-settings-daemon populates the Xrm database with the configured antialiasing options (Xft.*) on startup, using /etc/fonts/fonts.conf as defaults. Applications use the Xrm database to determine what the options are, but if they don't exist (e.g., "xrdb -remove -all") then the fontconfig parameters are used instead. Indeed this appears to be the behavior of most GTK/Qt applications.

Unfortunately OpenOffice.org doesn't follow this behavior, it relies on the Xrm database exclusively for the lcdfilter option (problem #1). And since GNOME doesn't know about the lcdfilter option, it doesn't populate the Xrm database with it (problem #2).

Fortunately there's an easy fix that appears to work without needing to downgrade packages or sacrifice font options. It's quite simple to add the Xft.lcdfilter parameter manually. This can be done for the current X11 session by running the following command in a terminal:

echo "Xft.lcdfilter: lcddefault" | xrdb -merge

After doing so, OpenOffice.org should have interface fonts that appear approprately filtered. To make the change persist after reboot, it can be stored in an Xresources file:

echo "Xft.lcdfilter: lcddefault" >> ~/.Xresources

Or to make the option system wide:

sudo sh -c 'echo "Xft.lcdfilter: lcddefault" > /etc/X11/Xresources/lcd-filter-lcddefault'

I've tested this on an Intrepid Live CD and it works well. I've not tested it on Jaunty, but I suspect it works there as well.

@Mike

Yes, it works on Jaunty too. Thank you very much!

Reassigning to Alexander since he knows how gnome/cairo integration works.

Alexander,

So I ran the following:

pango-view -t "CAIRO" --backend=cairo --font="Times New Roman"
pango-view -t "XFT" --backend=xft --font="Times New Roman"
pango-view -t "FT2" --backend=ft2 --font="Times New Roman"
pango-view -t "X" --backend=x --font="Times New Roman"

and got the attached screenshot...

It looks most closely like the cairo screenshot but I am not sure what you were getting at earlier with respect to the rendering.

Thanks,

Chris

Oh yea I forgot to mention it appears that pango-view does not allow you to set hinting to slight like what this bug was originally about, so that might be the difference?

Actuallly comparing gedit and OOo it does look like OOo's font anti-aliasing is darker, the same as comparing OOo and pango-view.

Alexander,

Here are the results from grep that you requested.

Chris

Thank you Mike! Your xrdb workaround fixes the issue.

so do we want this for lcd screens only or everywhere?

OK, i made a patch that enables lcddefault for setups that use_rgba and uploaded gnome-settings-daemon to my ppa: https://edge.launchpad.net/~asac/+archive/ppa ... pleas install gnome-settings-daemon from there and restart your system to test.

p.s. we have a hard freeze in just two days or so ... so please test asap ;).

also i found something else in cairo; can you confirm that using lcdlegacy e.g.

  echo "Xft.lcdfilter: lcdlegacy" | xrdb -merge

is the same brokeness you see by default?

Alexander,

I don't fully understand what is going on... but I think we want this to work in such a way that OOo looks the same as the rest of the apps no matter which option is set in System->Preferences->Appearance->Fonts, at least if this is possible.

I'll try to give your ppa a test to see if it works for me, but also getting Mike to test it would be best since he seems to fully understand the issue.

Thanks,

Chris Cheney
OOo Maintainer

For some reason this still doesn't look exactly the same as gedit with the same font/size. But it does seem to look better to me.

Mike any comments?

Ok after my thinko... forgot to restart gnome-settings-daemon things started looking better. :-)

However I did notice another related bug here:

Setting font hinting to slight does not update the xrdb info, eg:

 xrdb -query
*customization: -color
Xcursor.size: 18
Xcursor.theme: Human
Xcursor.theme_core: true
Xft.antialias: 1
Xft.dpi: 125
Xft.hinting: 0
Xft.hintstyle: hintnone
Xft.lcdfilter: lcddefault
Xft.rgba: rgb

==

Xft.hintstyle never changes to hintslight... it stays at what you had last selected before switching to slight. Thus this causes OOo not to look like the other applications when slight hinting is selected.

Chris

Er the Xft.hintstyle setting from gnome-settings-daemon appears to be totally FUBAR. I can easily get it to screw up for every setting it seems.

It seems when it is screwed up if you go back to System->Preferences->Appearance->Fonts->Details it will update it at that point. So it appears changing the selection does not immediately update xrdb until you go back into the details page a second time, maybe?

The issue I am seeing appears to be some sort of threading issue in spawn_with_input() in the xft_settings_set_xresources() call. I will be filing that issue as a separate bug.

The bug I filed about the threading issue is bug 356620.

i dont think that Xft.XXXX is supposed to update instantaneously ... rather change the setting and relog in before it becomes effective everywhere. if not its a bug, yes.

... remember that this xrdb thing is kind of a legacy thing.

OK back to topic: Did you say that this patched helped or not? (Please always relog-in after changing that setting)

Yes, it appears to fix the issue.

The other issue I saw appears to be a race issue as seen after adding logging, more information is in the upstream report linked by the other launchpad bug.

Patch appears to make things work appropriately on my end. It looks great.

attaching patch i previously uploaded. Can you please also look at other apps and say if you see any problems with that?

gnome-settings-daemon (2.26.0-0ubuntu4) jaunty; urgency=low

  * debian/patches/40_xres_lcddefault.patch: fix LP: #271283 - OpenOffice.org
    subpixel font rendering broken with new cairo

 -- Alexander Sack < <email address hidden>> Tue, 07 Apr 2009 11:49:01 +0200

The real issue is probably in the cairo patch we carry for lcdfiltering; This wont be fixed for jaunty though as touching that code is just too risky so close before the release and i have other things to do anyway ;).

moving to post jaunty; keeping assigned to me; at best we would finally get the lcdfilter patch into upstream cairo.

If we do get our cairo patch into upstream we probably would want to push the g-s-d patch to upstream at that time as well. Unless the g-s-d patch is already useful to send to them now.

Re: 40_xres_lcddefault.patch

Haven't seen any issues with it in other applications.

The only problem outstanding that the patch doesn't address is that there's currently no easily configurable way to change which lcd filter to use (lcddefault, lcdlegacy, lcdlight, etc.) except to change the xrdb entry after gnome-settings-daemon has loaded. Granted, this was the case before the patch too, and at least now the behavior is consistent across applications.

But ideally now that gnome-settings-daemon is "aware" of the lcdfilter option, the GUI should be updated with ability to change it. This probably makes most sense to coordinate with upstream after the lcdfilter patches are accepted into cairo.

In Jaunty i still see the issue. Looks like openoffice does better hinting but still not the same as the other gnome/qt apps.

After doing echo "Xft.lcdfilter: lcddefault" | xrdb -merge it does work

The problem is still present in the tabs labels. For example, this is an screenshot of the Tools->Customize dialog. You can see that the "Keyboard", "Toolbars" and "Events" tabs shows without antialiasing.

My previous screenshot was in Spanish. Here's the English equivalent.

On Tue, Apr 07, 2009 at 03:53:19PM -0000, Mike Kasick wrote:
> Re: 40_xres_lcddefault.patch
>
> Haven't seen any issues with it in other applications.
>
> The only problem outstanding that the patch doesn't address is that
> there's currently no easily configurable way to change which lcd filter
> to use (lcddefault, lcdlegacy, lcdlight, etc.) except to change the xrdb
> entry after gnome-settings-daemon has loaded. Granted, this was the
> case before the patch too, and at least now the behavior is consistent
> across applications.

Isn't this filtering something thats supposed to be configured for
each font individually (through fontconfig)? From what i understood
this change was only needed because openoffice doesnt properly honour
fontconfig settings for lcdfilter.

 - Alexander

On Thu, Apr 30, 2009 at 01:24:33PM -0000, Ricardo Pérez López wrote:
> My previous screenshot was in Spanish. Here's the English equivalent.
>
> ** Attachment added: "openoffice-english.png"
> http://launchpadlibrarian.net/26177231/openoffice-english.png
>

Please open new bugs for issues left after the patch we applied for
this bug. Thanks!

 - Alexander

El mar, 05-05-2009 a las 19:06 +0000, Alexander Sack escribió:
> On Thu, Apr 30, 2009 at 01:24:33PM -0000, Ricardo Pérez López wrote:
> > My previous screenshot was in Spanish. Here's the English equivalent.
> >
> > ** Attachment added: "openoffice-english.png"
> > http://launchpadlibrarian.net/26177231/openoffice-english.png
> >
>
> Please open new bugs for issues left after the patch we applied for
> this bug. Thanks!
>
> - Alexander
>

Thank you very much for the reply, Alexander. I've just opened a new
bugreport (bug #372670) against openoffice.org package and I subscribed
you to it. Hope this helps.

Cheers.

not sure what still needs to be done on cairo side here.

Hey guys, was that gnome-settings-daemon patch ever filed upstream?

Can you please help on getting this patch upstreamed?
https://bugzilla.gnome.org/show_bug.cgi?id=631924

Looking at upstream bug, looks like their are willing to accept the patch, but would like to see an updated patch against current code.

Thanks