Description of problem: Font hinting is apparently wrong in some hint level / sub pixel combinations. I see ugly font rendering in Firefox and all GTK apps. Things are better in KDE, but I'm not sure rendering quality is optimal. Version-Release number of selected component (if applicable): freetype-2.1.10-5.2.1 gtk2-2.8.15-1 qt-3.3.5-13 How reproducible: 100% Steps to Reproduce: With subpixel rendering enabled and hint=medium on KDE desktop, launch Firefox. The rendering of fonts in Firefox is much worse than all KDE apps. Running GNOME doesn't appear to solve the problem; on the contrary, the entire desktop has low quality font rendering. Actual results: Bad looking font rendering. Expected results: Good looking font rendering, as obtained in Fedora Core 4. Additional info: I will attach a composition of screenshots and explain what I think is wrong.
Created attachment 127209 [details] How fonts are rendered in KDE/GNOME with subpixel on/off and hint level off/light/medium/full I see some problems: 1) Subpixel off: hinting is too weak. Look at the "nu" in "Menu" or the ":" or the "li" in Application. Even with hinting=full, we never get alignment to a pixel border. 2) Subpixel on: hinting is too strong, expecially in GNOME. Look at the "Document" string: even with hint=light, we get total alignment to pixel border (not even subpixel border, but entire pixel). Light or medium or full gives no difference, it looks like it is always "full". I'd say that maybe the code is quantinzing to full pixel when subpixel rendering is on and to subpixels when subpixel rendering is off (the opposite of the correct behavior). Add to this the apparent "always full" hinting in GTK apps. I usually run KDE with LCD+hint=medium setting and rendering quality is generally good, but in Firefox (gtk) the hinting is so strong that the output is very similar to not-antialiased, not-subpixel render. In fact, disabling subpixel rendering improves the quality because the hinting becomes weaker.
This bug could explain bug #186593.
I got a small improvement by using the following patch, as advised on the freetype mailing list. http://lists.gnu.org/archive/html/freetype/2006-04/msg00012.html But the problem is still present. "Serif" text in Firefox remains almost unreadable. --------------------------------------------------------------------------------------------- Index: src/autofit/aflatin.c =================================================================== RCS file: /cvsroot/freetype/freetype2/src/autofit/aflatin.c,v retrieving revision 1.34 diff -u -r1.34 aflatin.c --- src/autofit/aflatin.c 21 Mar 2006 16:30:04 -0000 1.34 +++ src/autofit/aflatin.c 4 Apr 2006 13:11:06 -0000 @@ -1344,14 +1344,14 @@ * We snap the width of vertical stems for the monochrome and * horizontal LCD rendering targets only. */ - if ( mode == FT_RENDER_MODE_MONO || mode == FT_RENDER_MODE_LCD ) + if ( mode == FT_RENDER_MODE_MONO ) other_flags |= AF_LATIN_HINTS_HORZ_SNAP; /* * We snap the width of horizontal stems for the monochrome and * vertical LCD rendering targets only. */ - if ( mode == FT_RENDER_MODE_MONO || mode == FT_RENDER_MODE_LCD_V ) + if ( mode == FT_RENDER_MODE_MONO ) other_flags |= AF_LATIN_HINTS_VERT_SNAP; /* ---------------------------------------------------------------------------------------------
Just discovered that Firefox render is perfect when using MOZ_DISABLE_PANGO=1. I attach two screenshots.
Created attachment 127430 [details] Firefox screenshot. Font render quality is very low. (this picture has to be observed on a RGB LCD)
Created attachment 127431 [details] Firefox screenshot with MOZ_DISABLE_PANGO=1. Font render quality is very good. (this picture has to be observed on a RGB LCD) Firefox has been launched with "MOZ_DISABLE_PANGO=1 firefox".
Changed component to pango, as it seems more appropriate.
*** This bug has been marked as a duplicate of 186593 ***