Bug 489833 - Default Font Rendering is Poor
Default Font Rendering is Poor
Product: Fedora
Classification: Fedora
Component: freetype (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Behdad Esfahbod
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-12 01:20 EDT by Chris Wood
Modified: 2009-03-21 20:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-12 01:28:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Wood 2009-03-12 01:20:58 EDT
Description of Bug:
In Fedora 10, fonts are by default rendered poorly in terms of legibility and proportion. 

While this problem is in reality systemwide with ALL fonts, it is most noticeable in Firefox and OpenOffice. In Firefox, fonts are too big proportionally no matter how font settings are changed in Edit|Preferences. They look about 1 size bigger or smaller than they should be. 

In OpenOffice, fonts do not appear antialiased at all (regardless of sans serif or serif or system hinting settings) and the edges of the letters appear very jagged instead of smooth. One can observe a similar phenomenon in AbiWord as well. This makes documents difficult to look at for extended periods of time. 

A long time ago, Debian/Ubuntu had similar problems with fonts, but they patched the font rendering packages and now the problem is fixed in those distros. Fedora has not done the same and this problem has persisted through many releases with no action being taken. 

This is most emphatically NOT a bug with Firefox, Abiword, OpenOffice or any other external program. This has to do with Fedora itself, as one can clearly see from the descriptions that follow. 

Steps to fix bug:
After much research, packages located at 
http://www.bevenhall.se/jim/fedora-cleartype/ were found to completely fix the problem.

Steps as quoted from http://www.bevenhall.se/jim/fedora-cleartype/
"Tired of crappy and ugly fedora fonts?
Download and replace these rpms for F8 or F10.
'rpm -Uvh --replacepkgs --force cairo-* freetype-* libXft-* msfonts-*' [NOTE: msfonts-* is COMPLETELY optional, only useful if one wishes to use those fonts. /NOTE]
Restart X to make sure everything is reloaded.
Turn on and adjust antialiasing and subpixel smoothing.
Enjoy "cleartype enabled" fonts.
Thanks to jaganath for the patch tips and thanks to Erik for the 64-bit rpms."

The result of the above fix:
Fonts are now beautiful and easy to read systemwide. 
They antialias well across the system and proportionally scale well in Firefox. 
These packages are freely redistributable as Fedora installs them by default (albeit the unpatched versions).

Clearly, it is not a problem with the fonts individually. 
Rather the bug concerns the font rendering packages cairo, freetype, and libXft.

Steps to Reproduce:
Simply compare the font-rendering quality of a default Fedora 10 install to an install that was patched with these packages. Simply a matter of before and after.
To fully see changes, one should be sure to "Turn on and adjust antialiasing and subpixel smoothing." as mentioned in the steps above after restarting X.

Other bugs that are completely fixed by the patched packages are:

A personal appeal:
I appeal to the community to please make this a priority before the next release. 
I just don't want people to be turned off Fedora because of it's poor default font rendering.
As one can see from the bug reports above, this problem has lingered for years now. It is in fact a legitimate bug and it deserves attention. Fedora is a great distro and this is really the main thing keeping it from realizing it's true potential from a user perspective.
Comment 1 Kevin Kofler 2009-03-12 01:28:14 EDT
We cannot enable these features in Fedora because they violate software patents.

You can try the freetype-freeworld packages from RPM Fusion, but these packages do not carry Ubuntu's antialiasing patches which are not upstream, they only enable the bytecode interpreter and subpixel antialiasing from upstream freetype (which cannot be done in Fedora due to software patents).

The only complaint which sounds valid is this one:
> In Firefox, fonts are too big proportionally no matter how font settings are
> changed in Edit|Preferences. They look about 1 size bigger or smaller than they
> should be.
I've also noticed GTK+ apps displaying larger fonts at the same point size and dpi than Qt apps. 94 dpi in pango is about the same size as 96 dpi in Qt. But this is a completely separate issue, it has nothing to do with the patent-encumbered patches you're referencing.
Comment 2 Nicolas Mailhot 2009-03-12 07:52:10 EDT
1. OO.o behaves differently since it uses a different text stack. This is being fixed upstream, you can ask OO.o devs to accelerate the move to pango/cairo if you like

2. GNOME font sizes are different: this is a result of GNOME allowing the overloading of DPI value in gconf instead of using the Xorg DPI value as everything else. Complain GNOME-side. DE people need to be hit with a huge cluestick and leave DPI to X (and modify this value at the X level if needed not in private overlays others apps do not see)

3. Cleartype. Not going to happen for legal reasons. Additionnaly it only performs good on very specific hardware, and very specific fonts (MS fonts which have bugs cleartype hides; we're not going to optimise our display for fonts we do not ship to the detriment of fonts we do ship). For every comment you'll find on the net praising those patches you'll find three stating they suck and make things worse. (likewise for Ubuntu vs Fedora text rendering)
Comment 3 Kevin Kofler 2009-03-12 11:06:41 EDT
ad 2. It's not that. My screen reports a resolution which is basically 96×96 dpi, and I even tried forcing both KDE and GNOME to exactly that, GTK+ apps still display larger fonts at the same size. Only when setting GTK+/GNOME to 94 dpi did I get approximately the same size (but not quite as nice looking fonts as with 96 dpi, though I got used to that).

What happens is that if I turn down the hinting (autohinter, mind you, I don't have freetype-freeworld installed, I only maintain it ;-) ), the effect disappears (but the fonts look bad), the stronger the (auto)hinting, the larger GTK+'s fonts get and the smaller Qt's. Somehow they use different algorithms. :-(
Comment 4 Jud Craft 2009-03-21 20:31:23 EDT
Ditto on the addendum for #2:  GTK actually reads its DPI from Xrdb, like everyone else.  It behaves remarkably well.

I believe it uses GConf as a way to store DPI changes on the fly.  At logon, it loads the GConf value into Xrdb.  A useful way to store the user-preference without being Xrdb dependent.

Also, Kevin.  I'm pretty sure they use the exact same algorithms -- my guess is they have some DPI rounding problems.  Example, if you vary Deja Vu Sans, sizes 9 and 10, DPI 94, 96, 98, and hinting between slight and full, you'll notice that Qt and GTK can render nearly identical glyphs -- but at different DPIs.  (What's even weirder is that hint-slight on Qt/GTK will mismatch on entirely different DPIs than hint-full.  Slight-9-96 will match, but Slight-9-98 won't.  Full-10-100 and Full-10-94 will match, but Full-10-98 and Full-10-96 won't.)

I was hoping sometime I could build a little visual guide to the discrepancies and post it to the Qt bug thing to see what they think.  I'm inclined to think the problem is a rounding bug on their side; GTK allows decimal DPIs (whatever that actually means) while Qt does not, so I'd suspect Qt first.

PS, I disagree partially with the "DE need to leave DPI to X".  I'm all for consistency, but the X model has inherent flaws of its own -- DPI and subpixel-format should be per-screen, not per-X-server, and X hasn't moved toward that yet.  The individual DE's and toolkits would currently be in a better position to use Xrandr and change their rendering based on per-screen settings, than it would be for Xorg to redo their Server attribute paradigms, which would break a whole lot of crap.

Note You need to log in before you can comment on or make changes to this bug.