[Ubuntu] [hardy] font hinting does not work with libfreetype6 v. 2.2.1

Confirmed here; fonts do look absolutely terrible in Edgy's OOo.

Here's a screenshot of what Openoffice looks like on my Edgy box. Note the blurriness of menu items.

Just for comparison, here's what gedit looks like

Bug still there in 2.0.4~rc2. I'm no longer sure, if the above patch would fix the issue, since at least parts of it (I haven'n compared it line by line) are included in the version upstream.

A temporary workaround would be, to copy the libfreetype from the dapper-package as libfreetype.so.6 into the /usr/lib/openoffice/program -directory. This causes openoffice to render display-fonts as you were used to in Dapper.

There are patches in Fedora-cvs which are trying to include full fontconfig-support (the lack for it is another annoying issue) for ooo, maybe at least parts of them would be helpfull for this issue, too. I would try it on my own, but there is no reasonable way for doing so, since the compile-time for building this monster on my Celeron 500 with 256 MB ram would be eternal.

After some investigation and reading Comments on Debian-Bug-Report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385798 it seems like openoffice simply is always using freetype-autohinter instead of respecting fontconfig-settings.

Turning on autohinter in ~/.fonts.conf causes, that GNOME-Apps and OOo are looking the same when using new freetype (but worse as if bytecode-interpreter is enabled).

So it seems like old freetype-lib in combination with openoffice uses bytecode-interpreter, new freetype not (why, I don't know).

I found these patches in Fedora-CVS, which are dealing with two upstream-issues which are related to this bug (I've chosen Fedora ones, because the patches attached to the issues may be out of date):

Patch to honor cairo-font-settings: (issue 59127 upstream)
http://cvs.fedora.redhat.com/viewcvs/devel/openoffice.org/openoffice.org-2.0.2.ooo59127.vcl.honourcairofont.patch?rev=1.1&view=auto
Patch to honor fontconfig-hinting (issue 64508 upstream)
http://cvs.fedora.redhat.com/viewcvs/devel/openoffice.org/openoffice.org-2.0.2.ooo64508.vcl.honourfontconfighinting.patch?rev=1.13&view=auto

Please check the test build announced on ubuntu-devel and ubuntu-users.

Looks good for me :)

Unfortunately not for me (although it seems to look better) - screenshot attached. Here you can see the most obious thing, that menu fonts still does not fit in gnome-environment.

Additionally, the workaround using libfreetype from dapper now does not work as expected. Fonts are still better with it, but are a bit bolder than in other apps (I guess medium instead of strong hinting, which is default on my machine). In the changelog is no specific hint what exactly was changed. Did you apply the patch, Bernd Schubert proposed in debian-bug-report?

I just find out something that doesn't make any sense from an user POV.
I created a .fonts.conf file which enables subpixel rendering, and now openoffice menu looks much better to me.
But it gives the same result as using "Best Contrast" in gnome, which is Grayscale antialiasing with full hinting. There is no subpixel rendering. If I try to only enable antialiasing and full hinting in fonts.conf, it doesn't work. Subpixel needs to be enabled (rgba sets to rgb), and it's enough.
So to sum up, for openoffice to look better, you need to enable an option that isn't used by openoffice.

So there are several issues:
- openoffice behaves weirdly to fontconfig settings (other apps work fine with just the Xft resources, and the fonts rendering match the settings)
- no subpixel rendering? (didn't manage to enable it)
- still no native hinting? (I believe it's still using autohinting, but I'm less positive on this one)

just to be safe, since I just got caught myself, the .fonts.conf file is a xml file, so its contents won't be displayed directly in firefox. just save the file, or view the source.

Confirmed bug. Please see the horrible font problem in the preference/options window attachment provided. Some letters are not even shown, others have strange bendings (r looks line n with shadow).

gedit with the same text without font problem for comparison.

That's a totally different bug.
This one may be closer :
https://launchpad.net/distros/ubuntu/+source/xorg/+bug/62537

Thank you Xavier.

I'm suffering from this issue too...

Firefox/Epiphany might also be affected:
https://launchpad.net/distros/ubuntu/+source/firefox/+bug/66079

I want to ask if this bug will be fixed before Edgy will be released.

It is a clear regression from Dapper Drake if OpenOffice.org is shipped with fuzzy fonts in the menu and inside as the default configuration.

- Using verdana fonts from msttcorefonts
- Font Rendering is set to Monochrome
- Smoothing set to none
- Hinting set to Full
- OpenOffice Tools>Options>View I tick the "Use system font for user interface" and uncheck "Screen font antialiasing".

Please note the above settings I have always used in previous versions of Ubuntu and all fonts in all packages displayed fine. It is only openoffice that is affected.

The attached screenshot shows openoffice.org writer and gedit using the same font being Verdana, notice the difference.

Yep, still looks like crap...

I also upgraded my kubuntu box from dapper to edgy a few days ago. I am using true type fonts for QT, GTK1, GTK2 apps - all worked fine with dapper. Though, after the upgrade, all fonts in openoffice (menu+text) look terrible.

see attached screenshot showing the openoffice fonts compared to whats available to KDE's Kcontrol....

I would be very unhappy if this bug would not be fixed...

> see attached screenshot showing the openoffice fonts compared to whats available to KDE's Kcontrol....

I don't see a difference in these; is anti-aliasing turned off by default for KDE?

comment 9:

>Unfortunately not for me (although it seems to look better) - screenshot attached. Here you can see the most obious thing, that menu fonts still does not fit in gnome-environment.

does this change for you when using subpixel-rendering (in the advanced gnome font settings)

>I don't see a difference in these; is anti-aliasing turned off by default for KDE?

No it isn't, but does it matter?
And you really don't see the difference? It's the difference between ugly and beautiful fonts.
Though, you're right, this screenshot is different than the others. First, there is no antialiasing in openoffice and kde. Second hinting seems enabled for openoffice fonts.
The problem here is it isn't the same hinting. Openoffice fonts use autohinting, but every other apps use native hinting.
Anyway, openoffice should use all fontconfig settings (in /etc/fonts/ , ~/.fonts.conf and Xft resources) and use them, instead of ignoring them all.

comment 23:

>does this change for you when using subpixel-rendering (in the
>advanced gnome font settings)

No, it does not. You still did not tell if you applied Bernd Schuberts patch, or not. If so, please revert it, it is worse for me than it was.

I tried the edgy eft daily live cd from today 20061024 on my desktop (Athlon 64, nvidia) and on my Dell Intel laptop (ATI graphics) and on both the problem persists.

Screenshot attached: 300% zoom, first menu is OpenOffice.org, second menu is gedit.

When I use subpixel smoothing and full hinting, the menu fonts get better, but text inside renders very strange.

In the screenshot, you see that the word "text" in OOo renders very bad - parts of the letter "t" are not shown and "e" and "x" are positioned too far away. (I changed the fonts in gedit to use the Bitstream Vera Serif one.)

2006/10/24, Oskar Rubinstein <email address hidden>:
> When I use subpixel smoothing and full hinting, the menu fonts get
> better, but text inside renders very strange.
>
> In the screenshot, you see that the word "text" in OOo renders very bad
> - parts of the letter "t" are not shown and "e" and "x" are positioned
> too far away. (I changed the fonts in gedit to use the Bitstream Vera
> Serif one.)
>
> ** Attachment added: "Screenshot 2"
> http://librarian.launchpad.net/4934068/screenshot2.png
>
> --
> [Edgy] font hinting does not work with libfreetype6 v. 2.2.1
> https://launchpad.net/bugs/54776
>

That's probably the difference of autohinting vs native hinting. Could you try "sudo dpkg-reconfigure fontconfig-config", use autohinting, and compare again.

> That's probably the difference of autohinting
> vs native hinting. Could you try
> "sudo dpkg-reconfigure fontconfig-config",
> use autohinting, and compare again.
Unfortunately it makes no difference.

here are two more screenshots...

I use ms truetype fonts. the quality apparently gets worse when I use autohinting. so, why should I use autohinting instead of native?

the quality of OO is bad in both cases...

hanswurst schrieb:
> here are two more screenshots...
>
> I use ms truetype fonts. the quality apparently gets worse when I use
> autohinting. so, why should I use autohinting instead of native?
>
> the quality of OO is bad in both cases...

the two screenshots are not OOo, but KDE. Jonathan, I do have absolutely
better font quality on my recent Kubuntu installations (and on the live
DVD); hanswurst, please get a screenshot from the current live CD / DVD.

On debian, the workaround of enabling subpixel rendering in ~/.fonts.conf didn't work, maybe because it doesn't apply the patches from fedora cvs pasted above. (It's maybe better that way, because it didn't make any sense).
As Bernd Schubert said in the bug report, light hinting (=slow=medium) is hardcoded in openoffice.
Hardcoding normal hinting (=full) works fine.

I installed his packages from there:
http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/openoffice/
I'm nearly sure he just applied his patch from there:
http://bugs.debian.org/cgi-bin/bugreport.cgi/normal_hinting.patch?bug=385798;msg=69;att=1
Though, a confirmation is required.
Anyway, his packages result in nice fonts for me, both with or without antialiasing.

That said, having font settings hardcoded isn't acceptable, because users have very different font preferences.

AFAIK, the fedora-patches (which should provide fontconfig-support) aren't applied in ubuntu. Simply hardcoding other settings wouldn't fix the issue. Only full fontconfig-support would be a solution for every setup possible.

Gert Kulyk schrieb:
> AFAIK, the fedora-patches (which should provide fontconfig-support)
> aren't applied in ubuntu.

Gert, please don't speculate; the patches are applied.

  apt-get source openoffice.org
  dpkg-source -x openoffice.org_*dsc
  cd openoffice.org-2.0.4
  apt-get install build-dep openoffice.org
  debian/rules build

you can stop building when all the tarballs are unpacked and the patches
are applied.

Xavier schrieb:
> As Bernd Schubert said in the bug report, light hinting (=slow=medium) is hardcoded in openoffice.
> Hardcoding normal hinting (=full) works fine.
>
> I installed his packages from there:
> http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/openoffice/

I don't see the .diff.gz/.dsc on this site, do you know where these are
available?

> I'm nearly sure he just applied his patch from there:
> http://bugs.debian.org/cgi-bin/bugreport.cgi/normal_hinting.patch?bug=385798;msg=69;att=1
> Though, a confirmation is required.

AFAICS the patch doesn't apply anymore; a similiar patch has been applied.

Matthias Klose schrieb:
>> AFAIK, the fedora-patches (which should provide
>> fontconfig-support) aren't applied in ubuntu.

> Gert, please don't speculate; the patches are applied.

I did not mean the fontconfig-stuff that is fixing issue 54603 (these patches are applied, I know), I meant the fontconfig-hinting stuff that is fixing issue 64508 (at least the changelogs and the apply files I've seen do not indicate, that fixes for this issue are applied). But I may be wrong . At the moment I'm downloading the latest sources, so I'll have a look on them.

To Matthias:

The latest source does indeed apply the patches - sorry for the traffic.

I was also surprised when I learned these patches were applied.
They apparently don't work as expected.

OOo seems to use greyscale and not subpixel hinting like everything else in latest feisty, I suppose that's because of this bug.

Confirm this is still present in Feisty (herd5 + all updates to 19 Mar) for me. Looks really really ugly, see attached screenshot comparing Firefox 'File' menu with that of OO.o Writer.

Full subpixel hinting.

Oops, here's the attachment.

Font rendering seems okay to me with OpenOffice 2.2.0. The UI is clean and sharp again. See Screenshot.

Ooops, sorry, wrong screenshot attached...

The fonts in that screenshot aren't anti-aliased at all.

No, they aren't. That's because I really can't stand anti-aliased fonts, those blurry looks give me a headache after a while. I prefer clear, sharp fonts and turn on anti-aliasing only for larger fonts, if at all.

OOo in Edgy makes disabling AA a no-go, because the fonts become almost unreadable; for me, the rendering in Feisty's OOo 2.2.0 is fine.

Here's a screenshot from a machine running current Edgy, anti-aliasing turned off. Notice the ugly small fonts and the UI?

I can confirm that the problem still exists on Feisty.

Substituting ``DejaVu Sans Condensed'' with ``Sans'' as proposed in thread: http://www.ubuntuforums.org/showpost.php?p=2262565&postcount=6 does the trick. Not a long term solution but the fonts look nice again.

Problem still exists in final Fesity release. Also seems to affect AbiWord and many other apps, so OOo may not be alone...

Do you have, or have you had, KDE installed? It messes with Gnome's font settings in ~/.fonts (iirc). If you have that file could you try removing it and restarting Gnome? The problem is gone on my Feisty install, including with Abiword.

However, although its a separate issue, I really think this problem with KDE messing up Gnome's fonts needs fixing.

Er, no, the Deja Vu Sans Condensed issue was fixed, but it still always uses grayscale hinting

It's using sub-pixel for me. Image attached.

Tolan:

No KDE apps installed, it is a plain vanilla Ubuntu install.

Erm, Tolan? That looks like a screenshot of Abiword, this bug's about OpenOffice.org

VF, please see jclemon's earlier comment about Abiword.

Jclemon, ok, just a suggestion, as removing the file KDE had created fixed this for most things, then an update to OO.o fixed it for that for me, so I thought you could have received the fix but still been suffering from the ~/.fonts issue.

Fair enough, but that's a different bug so it probably shouldn't be discussed here

This issue no longer seems to affect Abiword or OpenOffice, I don't know if any fixes were released since my last comment were regards to this. I see a fix has been implemented in Debian at least.

OO.org still uses grayscale hinting, not subpixel when selected on Gutsy

the bug is still there in gutsy. I am pasting my screen shot for firefox and open office. Open office does not honour the subpixel smoothing. I have mine set to slight and it works perfectly for all apps only open office does not use it.

Also, this bug is in there for almost a year now. Not sure what fixes are being done on this bug. Though there is some improvement it is not fully fixed.

The difference is clearly visible in the menu text. Please zoom to image to 100% then it would be easy for you.

Yes, I can confirm this on released Gutsy. And that the workaround posted by zermy (in reference to a forum post) no longer works. The attached screenshot uses Liberation fonts.

This is pretty annoying here (Kubuntu Gutsy/ OOo 2.3, too!)
I found another thread covering this topic:
https://bugs.launchpad.net/baltix/+source/openoffice.org/+bug/138493
I am back to wine/MS Office until it's fixed. I just realized it bothers me quite a bit!
--hasi.

Hasi, but does it mean that you have been able to get subpixel renedering in MS Office on Wine? If so - I would be interested in details...

Sorry for the confusion, guys. I have been quite heavily using OOo and MS Word 2003 in parallel for a few weeks now (for several reasons). I could have sworn that the fonts look nicer in Word. When I was trying to prove it doing some snapshots, I found they practically look the same (see screenshot)!
Now I am puzzled why that is. I actually am shocked facing the possibility that I may be positively biased for MS product...
One difference may be that on my current settings, I have the minimal size for the AA in OOo to "1", whereas the AA seems to be switched off in my wine/MS Word settings for the smaller fonts. That may have caused my impression. Similarly, in my snapshot, the menus in Word are not AA'ed at all, whereas OOo does its not-so-perfect AA. I actually prefer no AA at all in that case!
--hasi.

Still present in Hardy Alpha 2 :( See screenshot - global subpixel is on (as seen in e.g. Gnome top panel menu), in OOo only grayscale hinting is used (and - but this is another issue - default document font looks terrble) :(

Seems like Caolan McNamara is working on the subpixel-rendering issue, making use of cairo for text-rendering.
Have a look at http://blogs.linux.ie/caolan/2008/01/24/144/ and
http://qa.openoffice.org/issues/show_bug.cgi?id=85470

Here a screenshot how it will look like, when above mentioned patch will be integrated upstream. Upstream-packaged version (en-US-packages only, but a current upstream-langpack-snapshot should work when copied to the right place) can be found here: http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/cairotext01/

For comparsion, a shot of the gutsy-package, displaying the same content.

Gert - any hints on how to get it running in Gutsy? For "the rest of us" :-)

First, you'll need to download all rpm-files from the given location (the desktop-integration-packages are not necessecary for testing as well as the testtool package). Next you'll need to open a terminal and cd to the directory the downloaded files are and issue the following command:

"for PKG in *.rpm ; do rpm2cpio ${PKG} | cpio -i -d ; done"

This will unpack the rpm-files. You can start the app by issuing the following command:
PATH_TO_DOWNLOADED_FILES/opt/openoffice.org2.4/program/soffice (-writer, -calc, -impress etc.). It will use your ~/.openoffice.org2 config-directory, so please back it up or use a clean account for testing.

Please do not try to make a system-wide-install and do not use them for production - e.g. word-import sometimes is unreliable in this build (but this seems not to be related to the cairotext-patch).

The main reason for this post was to mention the upstream-efforts in coping with this annoying issue, unfortunately it seems like it will not be included in upstream-2.4-release.

So I hope the members of the openoffice.org-scribblers-team will include the above mentioned patch for hardy. (It seems like fedora-cvs has an updated one for the 2.4-line to be included in fedora 9).

Here's the URL for Fedora's cairotext patch:

  http://cvs.fedora.redhat.com/viewcvs/rpms/openoffice.org/devel/workspace.cairotext01.patch

We need this patch applied to Hardy 8.04 before official release.
Too many years are passed with those crappy fonts on OO.

I agree, this is ridiculous. This is the sort of thing that doesn't affect functionality but is profoundly upsetting for people.
It's been over a year now and this is quite an indictment of Ubuntu's bug-squashing abilities...

I am using Hardy and seems this has been fixed. I see that fonts are consistent with firefox or any gtk app and open office.

This is not fixed in Hardy yet, as indicated. Enable Subpixel Smoothing in Appearence prefs-> fonts and then compare openoffice's menu bar to firefox or any other gtk apps and the difference is immediately apparent.

Yep this isn't fixed in Hardy, yet. However, I believe that this will be fixed in the next upload, I have a patch that I still need to try out that should fix the problem. Of course if it 'improves' it to Firefox's level of support then I will likely get a lot of bugs about it crashing. As soon as I changed the font setting in Gnome it caused Firefox to crash on my machine.

This bug was fixed in the package openoffice.org - 1:2.4.0-3ubuntu1

---------------
openoffice.org (1:2.4.0-3ubuntu1) hardy; urgency=low

  [ Chris Cheney ]
  * Resynchronise with Debian (r1044). Remaining changes:
    - debian/broffice.org.postrm.in:
      . Change diversions to ubuntu bitmap filenames.
    - debian/broffice.org.preinst.in:
      . Change diversions to ubuntu bitmap filenames.
    - debian/control.in:
      . Change maintainer line.
      . Use imagemagick instead of graphicsmagick.
      . Change bzr repo location.
      . Add package openoffice.org-style-human.
      . Add replaces openoffice.org-gtk (<< 2.0.3-1) for openoffice.org-gnome
        dapper upgrade.
    - debian/control.l10n.in:
      . Add file for Ubuntu.
    - debian/control.lang.in:
      . Add L10N_COMMON to Depends.
    - debian/control.mozilla.in:
      . Add Xb-Npp-xxx tags according to "firefox distro add-on suport" spec.
    - debian/control.ubuntu-feisty.in:
      . Add file for Ubuntu.
    - debian/deppackage.postinst.in:
      . Add file for Ubuntu.
    - debian/module-po.map:
      . Add file for Ubuntu.
    - debian/ooo-build-ubuntu.diff:
      . Various Ubuntu specific changes to ooo-build.
    - debian/openoffice.org-base.mime:
      . Update and sort mime-types.
    - debian/openoffice.org-calc.mime:
      . Update and sort mime-types.
    - debian/openoffice.org-draw.mime:
      . Update and sort mime-types.
    - debian/openoffice.org-filter-binfilter.mime:
      . Update and sort mime-types.
    - debian/openoffice.org-impress.mime:
      . Update and sort mime-types.
    - debian/openoffice.org-math.mime:
      . Update and sort mime-types.
    - debian/openoffice.org-writer.mime:
      . Update and sort mime-types.
    - debian/rules:
      . Add BUILD_SPARC option.
      . Add USE_COMMON_DOCDIR option.
      . Add USE_LZMA_COMPRESS option.
      . Add support to build on lpia.
      . Add support to build l10n as a separate source.
      . Add support to chmod +x programs in debian dir.
      . Add support to uuencode binary files in ubuntu dir.
      . Add support for Ubuntu specific bitmaps.
      . Add support for openoffice.org-style-human package.
      . Add support for launchpad translations.
      . Update location of aotcompile.py file.
      . Use imagemagick instead of graphicsmagick.
      . Use openjdk-6-jre instead of icedtea-java7-jre. Closes LP: #203636
      . Various Ubuntu specific changes.
    - debian/scripts/convert2po:
      . Add file for Ubuntu.
    - debian/scripts/fix_image_rgb:
      . Use imagemagick instead of graphicsmagick.
    - debian/scripts/gsifilter.py:
      . Add file for Ubuntu.
    - debian/scripts/splitgsi:
      . Add file for Ubuntu.
    - debian/template.desktop.in:
      . Add NoDisplay=true.
  * Resynchronise with ooo-build (r12081).
    - Closes LP: #54776, #62256, #105906, #113358, #131272, #137469, #138252
      Closes LP: #148552, #154940, #160988, #175983, #194759, #197451, #197622
  * ubuntu/*:
    - Update splash screen for OOo 2.4. Closes LP: #199193
    - Various Ubuntu specific changes.

  [ Matthias Klose ]
  * ubuntu/lpi2gsi: Add templates and conversion scripts to generate
    ...

Intrepid has a similar problem on my computer. Can anyone verify?

Here's a comparison screenshot of Openoffice (top) and Gedit (bottom) in Intrepid.

@Munchkinguy:
This time it is cairo, not freetype. Somewhere on launchpad is a report against OOo in intrepid. Until it is fixed (people are working on it), you can take from the hardy-packages the libraries libcairo.so.2 and libpangocairo-1.0.so.0 and put them to the /usr/lib/openoffice/program folder to get the hardy-behaviour back.