Ubuntu

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

Reported by Joe_Bishop on 2008-09-17
60
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenOffice
Confirmed
Medium
cairo (Ubuntu)
Medium
Unassigned
Jaunty
Medium
Alexander Sack
gnome-settings-daemon (Ubuntu)
Medium
Alexander Sack
Jaunty
Medium
Alexander Sack

Bug Description

[Ubuntu Intrepid Ibex]
https://bugs.launchpad.net/bugs/264254
OpenOffice font rendering looks ugly because of the latest cairo patches. There is workaround and patches to improve font rendering to the previous state, but it doesn't work for the OpenOffice.

Neil Munro (neilmunro) wrote :

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.

Changed in openoffice.org:
status: New → Confirmed
Neil Munro (neilmunro) wrote :

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.

Changed in openoffice.org:
status: Confirmed → New
Neil Munro (neilmunro) wrote :

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:
status: New → Incomplete

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.
>>
>
>

Chris Cheney (ccheney) on 2008-10-17
Changed in openoffice.org:
assignee: nobody → ccheney
milestone: none → intrepid-updates
status: Incomplete → Confirmed

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! :(

ddumanis (dave-davedumanis) wrote :

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

ddumanis (dave-davedumanis) wrote :

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.

ddumanis (dave-davedumanis) wrote :

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.

ddumanis (dave-davedumanis) wrote :

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.
>

Chris Cheney (ccheney) on 2008-12-02
Changed in openoffice.org:
importance: Undecided → Medium
milestone: intrepid-updates → jaunty-alpha-2
status: Confirmed → Triaged

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.

yaztromo (tromo) wrote :

@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.

Mark Baas (mark-baas123) wrote :

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.

Chris Cheney (ccheney) on 2009-01-17
Changed in openoffice.org:
milestone: jaunty-alpha-2 → ubuntu-9.04-beta
Chris Cheney (ccheney) wrote :

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

Thanks,

Chris Cheney

Changed in openoffice.org:
status: Triaged → Incomplete

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.
>

Chris Cheney (ccheney) on 2009-02-04
Changed in openoffice.org:
status: Incomplete → Triaged

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121711 Ubuntu/9.04 (jaunty) Firefox/3.0.5

With the new cairo (1.7.4+) subpixel font hinting is broken on OOo. If you go into Gnome System -> Preferences -> Appearance Preferences -> Fonts -> Subpixel smoothing (LCDs). Then the fonts have weird color fringing. As far as I know this is only an issue with ooo-build since upstream doesn't have the cairo patches.

Reproducible: Always

Changed in openoffice:
importance: Undecided → Unknown
status: New → Unknown
Changed in openoffice:
status: Unknown → Confirmed
philinux (philcb) wrote :

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

radek, can you look at this, seems like your area of expertise

Radek,

Any progress on this bug?

Chris

I am sorry, I am now busy with more important bugs, so no progress here :(

Mike Kasick (mkasick) wrote :

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.

Chris Cheney (ccheney) on 2009-03-21
Changed in openoffice.org (Ubuntu):
assignee: ccheney → nobody
milestone: ubuntu-9.04-beta → none
Fabrizio Narni (shiba89) wrote :

@Mike

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

Mike Kasick updated the Ubuntu bug report with the following information, maybe it is of some help with this bug:

"
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.
"

Changed in openoffice.org:
assignee: nobody → ccheney
milestone: none → ubuntu-9.04
Chris Cheney (ccheney) wrote :

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

tags: added: regression
removed: pet-bug
Changed in openoffice.org (Ubuntu Jaunty):
assignee: ccheney → asac
Chris Cheney (ccheney) wrote :

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

Chris Cheney (ccheney) wrote :

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?

Chris Cheney (ccheney) wrote :

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

Pausanias (pausanias) wrote :

Thank you Mike! Your xrdb workaround fixes the issue.

Alexander Sack (asac) wrote :

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

Alexander Sack (asac) wrote :

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 ;).

Alexander Sack (asac) wrote :

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?

Chris Cheney (ccheney) wrote :

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

Chris Cheney (ccheney) wrote :

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?

Chris Cheney (ccheney) wrote :

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

Chris Cheney (ccheney) wrote :

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.

Chris Cheney (ccheney) wrote :

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?

Chris Cheney (ccheney) wrote :

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.

Chris Cheney (ccheney) wrote :

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

Alexander Sack (asac) wrote :

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.

Alexander Sack (asac) wrote :

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

Alexander Sack (asac) wrote :

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

Chris Cheney (ccheney) wrote :

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.

Mike Kasick (mkasick) wrote :

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

Alexander Sack (asac) wrote :

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

Alexander Sack (asac) wrote :

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

Changed in gnome-settings-daemon (Ubuntu Jaunty):
assignee: nobody → asac
importance: Undecided → Medium
status: New → Fix Released
milestone: none → ubuntu-9.04
Alexander Sack (asac) wrote :

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 ;).

affects: openoffice.org (Ubuntu Jaunty) → cairo (Ubuntu Jaunty)
Changed in cairo (Ubuntu Jaunty):
status: Triaged → Won't Fix
Alexander Sack (asac) wrote :

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

Changed in cairo (Ubuntu):
milestone: ubuntu-9.04 → later
status: Triaged → In Progress
Chris Cheney (ccheney) wrote :

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.

Mike Kasick (mkasick) 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.

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.

Mark Baas (mark-baas123) wrote :

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

Mark Baas (mark-baas123) wrote :

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

Alexander Sack (asac) wrote :

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.

Alexander Sack (asac) wrote :

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

Changed in cairo (Ubuntu):
assignee: Alexander Sack (asac) → nobody
status: In Progress → Invalid
Gabriel Burt (gabaug) wrote :

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

Pacho Ramos (pacho) wrote :

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

Changed in openoffice:
importance: Unknown → Medium

(In reply to comment #6)
> Please accept:
>
> https://build.opensuse.org/request/show/89141

A few questions:

What happened to /var in xdm.tar.bz2? Why not doing the change in the tarball and extract into buildroot as before?

About this one:

+Xft.dpi: 96
+Xft.antialias: true
+Xft.rgba: rgb
+Xft.hinting: true
+Xft.hintstyle: hintfull
+Xft.lcdfilter: lcddefault

I need more details for these changes? What's the meaning of all these settings
and how are they going to change the font rendering? Aren't most of them already set as default in /etc/fonts/suse-hinting.conf?

Changed in openoffice:
status: Confirmed → Incomplete

> What happened to /var in xdm.tar.bz2?

Indeed I have corrected this.

> Why not doing the change in the tarball
and extract into buildroot as before?

So the changes to be visible.

> What's the meaning of all these settings
and how are they going to change the font rendering? Aren't most of them
already set as default in /etc/fonts/suse-hinting.conf?

This does not affect all applications.

> What happened to /var in xdm.tar.bz2?

err seems you confised the file with misc.tar.bz2. This file has no /var

(In reply to comment #8)
> > Why not doing the change in the tarball
> and extract into buildroot as before?
>
> So the changes to be visible.

Ok. I understand now.

> > What's the meaning of all these settings
> and how are they going to change the font rendering? Aren't most of them
> already set as default in /etc/fonts/suse-hinting.conf?
>
> This does not affect all applications.

Yes, but what about different applications from OpenOffice.org, which prefer
Xrm setting over fontconfig configuration? They will change behaviour. In
which way?

(In reply to comment #9)
> > What happened to /var in xdm.tar.bz2?
>
> err seems you confised the file with misc.tar.bz2. This file has no /var

Indeed. I was wrong. I apologize.

I suggest you to look at how it works in this appliance

http://susegallery.com/build/start_testdrive/350542/928772

where I use this Xresources file for a long time for best fonts.

hardcoding 96dpi is just plain wrong.

http://www.freedesktop.org/wiki/ScreenFontSettings shows the state of the art of 2009. 2011 uses fontconfig, but Xft.dpi is still read by e.g. kde to force DPI

Unfortunately fontconfig does not affect all applications.

I removed the DPI setting from the patch.

I vote for not accepting these global Xft settings changes at all, since I expect them to break our global fontconfig configuration. In particuar the fontconfig snippets being included via /etc/fonts/conf.d/.

To be sure: does this problem still exist with the recent LibreOffice, right? I'm asking because the original bug report is pretty old.

If yes, still I wonder whether putting rgba: rgb is correct. This is the key point of the bug, I guess, but meanwhile the sub-pixel rendering is OFF as default. So, doesn't it break the font rendering in LO as default?

IMHO, the right place to fix is either LO itself or gnome-settings-daemon. g-s-d can change Xrm on the fly. (Currently it's changing only some XSETTINGS_* atoms.)

Alternatively, we may write a helper program to parse fonts-cofig and change Xrm automatically. This can be called from xinit.

In anyway, as long as the rgba configuration can be changed later, setting this to a static value doesn't sound like a good solution to me.

I just tried to reproduce the problem on my machine under KDE3. It seems that without dpi set in Xresources LibreOffice uses a font larger than that used systemwide for the interface. I have KDE3, KDE4, Qt4, GTK2 applications all using the same font size and only LibreOffice using a font slightly larger.

This can be mitigated only by setting the DPI in Xresources.

As to subpixel hinting I have set it up in /etc/fonts/local.conf

> If yes, still I wonder whether putting rgba: rgb is correct. This is the key
point of the bug, I guess, but meanwhile the sub-pixel rendering is OFF as
default.

I think subpixel rendering is either on or off. You can supersede some settings and turn it on, but you cannot affect it in some wrong way if it is disabled.

Changed in openoffice:
status: Incomplete → Confirmed

Peter.Would you please take a look at this and help to assign to the right person? Thanks !

I wonder if the problem still exists on openSUSE-12.3.

Otherwise, I think that Thorsten is the best person to look at this.

Appears fixed on 12.3

I made a LiveCD image in Suse Studio and I was unable to get subpixel hinting working in 12.3. There is even no third-party refository as there is for 12.2. This issue prevents me from using 12.3 now.

Reopening because subpixel hinting does not work in 12.3 even at the same level as in 12.2.

My responsibilities have changed, returning bug to general LibreOffice maintainer pool.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.