fonts are incorrectly rendered due to not using system cairo

[Kees Cook]

Binary package hint: firefox

Firefox 3.6's fonts are not rendering follow the system configurations. It's really ugly on my LCD. :)

[Bugzilla-lostreality (bugzilla-lostreality)]

Created an attachment (id=248671)
What a menu looks like under 3.0a1

If you compare this to 2.0, you can tell that the right pixel is cut off of each line of text. It is most obvious on the lowercase 's' on the bottom two options shown in that picture. The left pixel is also cut off of each line, but it is harder to tell. All of the text is clearly "dimmer" looking and not properly aliased for cleartype display, causing it to not look as sharp as it should and does under 2.0 and other browsers. Another small change noticeable is the space between the T and F on the second and third lines is 1 pixel less in 3.0a1 for some reason.

[Bugzilla-lostreality (bugzilla-lostreality)]

Created an attachment (id=248672)
What a menu looks like under 2.0

[Googulator (netrolller-3d)]

It seems that Cairo is unable to correctly detect the subpixel ordering of the screen, and does a BGR-ordered ClearType on the text. Or maybe a result of both Cairo and Windows attempting to antialias the text.

[Googulator (netrolller-3d)]

Confirming bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1.

Further investigation shown that Cairo selects the wrong contrast level when rendering the text. Setting contrast to 1.0 using ClearType fixes the issue (although text will likely to look weird in other places if that is set). Probably Cairo incorrectly reads the contrast values and takes them as if they were squared (e.g. a level of 1.4 is treated as 1.4^2, that's around 2.0, while 1.0 is processed as 1,0^2=1.0). Another thing I noticed is that if you hover over the menu items, the bug disappears, but opening a submenu causes it to re-appear. Testcase coming soon.

[Googulator (netrolller-3d)]

Created an attachment (id=248910)
Testcase

Testcase. Hover over the menu in it to trigger the bug.

[Googulator (netrolller-3d)]

It looks like the culprit is in cairo-win32-font.c, judging from these comments (line 1186):

"* Otherwise, we need to draw using software fallbacks. We create a mask
 * surface by drawing the the glyphs onto a DIB, black-on-white then
 * inverting. GDI outputs gamma-corrected images so inverted black-on-white
 * is very different from white-on-black. We favor the more common
 * case where the final output is dark-on-light."

After that (at line 1212):

"* For ClearType, we need a 4-channel mask. If we are compositing on
 * a surface with alpha, we need to compute the alpha channel of
 * the mask (we just copy the green channel). But for a destination
 * surface without alpha the alpha channel of the mask is ignored"
(Let's not forget that our surface is semi-transparent, so it does have an alpha!)

And a few lines later (line 1225):

"* XXX: Hacky, should expose this in cairo_image_surface"

Probably this is a bug in Cairo itself, but it seems to need quite a major rewrite.

[Vladimir Vukicevic (vvuk)]

*** Bug 355972 has been marked as a duplicate of this bug. ***

[Dao (dao)]

*** Bug 357456 has been marked as a duplicate of this bug. ***

[Jwbaker-acm (jwbaker-acm)]

Created an attachment (id=289559)
Screenshot

Firefox 3.0 does something differently with on-screen type. This leads to excessive color fringing in some cases. Please see the attached screenshot (which may not make any sense if you don't use an LCD screen). The upper text is from Firefox 2.0 and the lower is from 3.0b1

[Roc-ocallahan (roc-ocallahan)]

Is it different from other GTK/Pango apps on your system?

[Jwbaker-acm (jwbaker-acm)]

Created an attachment (id=289572)
Screenshot of native text

Screenshot is the same sentence typed into gedit with the same font, Droid Sans 12.

[Roc-ocallahan (roc-ocallahan)]

Ok, I'm not really sure what's going on here. Michael might be able to help out next week.

[Sylvain Pasche (sylvain-pasche)]

This may be related to the cairo version. I could see differences in rendering between cairo 1.4 (native GTK apps) and the more recent Firefox cairo. See bug 375591 comment 6

[Stream (stream)]

Created an attachment (id=308313)
screenshot from lineage2.com

On hover the bug is still visible. See the attachment. Why this bug is not blocker, when clear type technology is used mostly in LCD monitors, and its full of them now.

[Dylan Grose (dkbg)]

Yes, I can confirm this behaviour as well on Ubuntu Gutsy and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008022304 Minefield/3.0b4pre. The problem is exactly as described by the bug creator.

[12345667890gregfdbdfsdbd (12345667890gregfdbdfsdbd-deactivatedaccount-deactivatedaccount)]

I can confirm the same problem on Fedora 9 and Manfield 3.0 beta 4.

[Sylvain Pasche (sylvain-pasche)]

*** Bug 375591 has been marked as a duplicate of this bug. ***

[Sylvain Pasche (sylvain-pasche)]

This is clearly a cairo issue. See:

https://bugs.freedesktop.org/show_bug.cgi?id=10301

Things are actually stalled upstream unfortunately. Ubuntu/Debian users are lucky because their cairo is patched against this bug.

[Tgstrick (tgstrick)]

Created an attachment (id=314121)
ClearType/Opacity bug in 3 Beta 5 - Inline HTML (No layers/DHTML)

Seems like this bug has gotten worse in 3 Beta 5... I'm using opacity to fade out adjacent month dates in our in-house web calendars, and in Beta 5 the '1' digits are suffering badly. This is all relatively positioned CSS, no floats, no z-indexing or layers. Problem goes away with ClearType turned off.

[6XGate (sixxgate)]

This bug also manifests itself in the chrome as well if the element or it's parent uses opacity or has rounded borders (-moz-border-radius) The Glasser extension screenshots show this problem alot:

http://www.neowin.net/forum/index.php?showtopic=632112

[Sauron-ubufox (sauron-ubufox)]

I absolutely consider the Glasser extension an essential now, but this bug is really bugging me quite a lot. I tried turning off ClearType, but the font looks absolutely hideous on a LCD monitor.

[Kliu (kliu)]

*** Bug 431904 has been marked as a duplicate of this bug. ***

[Aurelius-bw (aurelius-bw)]

The Glasser Extension does not work properly because of this ...

[Redsign (redsign)]

That's nothing new but there also many websites that just look crappy because of this. It's really sad that this doesn't get fixed for 3.0.

[Kliu (kliu)]

*** Bug 434666 has been marked as a duplicate of this bug. ***

[Bugzilla-dailybuzz (bugzilla-dailybuzz)]

Created an attachment (id=321706)
A sample HTML file showing css opacity usage with various color text and background

[Bugzilla-dailybuzz (bugzilla-dailybuzz)]

Created an attachment (id=321707)
opacity_test_p.html with cleartype enabled

Rendered in Firefox 3 RC1 on Windows Vista.

[Bugzilla-dailybuzz (bugzilla-dailybuzz)]

Created an attachment (id=321708)
opacity_test_p.html with cleartype disabled

Rendered in Firefox 3 RC1 on Windows Vista.

[Sylvain Pasche (sylvain-pasche)]

*** Bug 436760 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 370429 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 439804 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 439850 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 439872 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 440791 has been marked as a duplicate of this bug. ***

[Dsicore (dsicore)]

Don't think this would block the 1.9.1 release. Minusing.

[Regis-caspar+bz (regis-caspar+bz)]

*** Bug 433825 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

What I'm curious about is why painting ClearType text onto a surface with alpha forces cairo to take the software fallback branch in the first place. Gecko 1.8 never had problems with drawing ClearType onto something with opacity, so what is it about cairo surfaces that prevents direct drawing?

[Me-at-work (me-at-work)]

Does this bug depend on bug 407531, or vice versa?

[Kliu (kliu)]

(In reply to comment #28)
> Does this bug depend on bug 407531, or vice versa?
>

Neither.

[Bugzilla-moeffju (bugzilla-moeffju)]

The problem seems to be in ClearType since 1.0.4, see http://lists.cairographics.org/archives/cairo/2006-October/008081.html

There is also a 'very large hammer' fix in that thread (force surface format to CAIRO_FORMAT_RGB24).

[Mcs-pearlcrescent (mcs-pearlcrescent)]

Created an attachment (id=339121)
XUL testcase using <menupopup>

Someone else I am working with encountered this bug when creating a theme that uses rounded corners and transparency with menus. In case it helps someone debug the problem, I am attaching a XUL-based testcase.

[Mcs-pearlcrescent (mcs-pearlcrescent)]

Created an attachment (id=339123)
screenshot of XUL testcase result (ClearType on, scaled to 200%)

[Mcs-pearlcrescent (mcs-pearlcrescent)]

Created an attachment (id=339124)
screenshot of XUL testcase result (ClearType off, scaled to 200%)

[M-h-perris (m-h-perris)]

Created an attachment (id=347965)
BBC Homepage Snippet

This is now visible on the BBC Homepage. The link on the right of the attached image has been hovered once, and the color has changed. Once the cursor is moved out of the box, the color reverts to it's original incorrectly cleartyped style.

[Karlt (karlt)]

Changing summary to reflect the current manifestation of this bug.

[Googulator (netrolller-3d)]

It appears that Microsoft is at least partially responsible for this bug - Firefox 3.0b1 renders the testcases significantly better on Windows 7 beta 1 than on Windows Vista SP1. Attachment 248910 does not show any bug now, while attachment 321706 only gets the white-on-white one wrong (and even that one is much better than on Vista). Attachment 339121 now only shows the rightmost-pixels-cut-off bug, no contrast problem is visible.

[Googulator (netrolller-3d)]

Seems that the problem is the fact that we "just copy the green channel" to get the alpha channel. The following testcases clearly point to this:
data:text/html,<div style="background: white;"><div style="color: white; opacity: 0.999; font-size: 36px;">FAIL</div></div>
This one faintly displays the word "FAIL", even though it is white-on-white, and as such, should be invisible. What is visible appears to be a cyan line on the left (cyan=blue+green), and a yellow one on the right of the text (yellow=red+green); both colors contain the color green as a component.
These also show incorrect rendering:
data:text/html,<div style="background: red;"><div style="color: red; opacity: 0.999; font-size: 36px;">FAIL</div></div> (part of the red color is missing on the left side of the letters, black is visible)
data:text/html,<div style="background: blue;"><div style="color: blue; opacity: 0.999; font-size: 36px;">FAIL</div></div> (part of the blue is missing on the right of the letters)
data:text/html,<div style="background: cyan;"><div style="color: cyan; opacity: 0.999; font-size: 36px;">FAIL</div></div> (part of the blue color is missing, green shows through)
data:text/html,<div style="background: magenta;"><div style="color: magenta; opacity: 0.999; font-size: 36px;">FAIL</div></div> (red is missing on the left, while the right lacks blue)
data:text/html,<div style="background: yellow;"><div style="color: yellow; opacity: 0.999; font-size: 36px;">FAIL</div></div> (red is mising, green shows through)

These pass however:
data:text/html,<div style="background: black;"><div style="color: black; opacity: 0.999; font-size: 36px;">FAIL</div></div>
data:text/html,<div style="background: green;"><div style="color: green; opacity: 0.999; font-size: 36px;">FAIL</div></div>
data:text/html,<div style="background: lime;"><div style="color: lime; opacity: 0.999; font-size: 36px;">FAIL</div></div>

What I have noticed is that we only pass if R=0 and B=0, i.e. color=#00xx00, where xx is any hex number. This is because the only channel for which the alpha mask is correct is green, as we use the green channel for our alpha mask.
However, if any other channel is present, the alpha mask will show an off-by-one-subpixel problem, and the rendering of the non-green channels will be corrupted.

So, basically copying the green channel to the alpha channel is wrong, the actual alpha channel should take all color channels into account. This bug, probably coupled with a bug in ClearType in pre-7 Windowses, is the most likely cause of the misrendering.

I'll probably back with a proof-of-concept patch soon.

[Googulator (netrolller-3d)]

Created an attachment (id=358765)
WIP 0.000001: Move away from using the green channel as the alpha

Extremely-early preview of what I am working on right now.
With this patch, testcases involving extreme colors (white-on-white, black-on-black, #ff0000 on #ff0000, #00ffff on #00ffff) pass, but other tests still show errors, and real-life rendering is also still wrong. This is because the dummy maximum algorithm used in this patch is just a placeholder, and is definitely not correct. However, the basic structure of the _compute_argb32_mask_alpha function is in place, only an alpha-channel generation algorithm is needed. I think I need to convert the RGB colors to HSL and use the lightness value as the alpha, although I am not sure.

If you have an idea what the correct algorithm would be, please post it here!

[Zurtex (zurtex)]

*** Bug 457538 has been marked as a duplicate of this bug. ***

[Jürgen 'jiha' Harter (jiha-bugzilla)]

Trying to build SeaMonkey on a ubuntu 9.04 machine. It builds fine when --enable-system-cairo is not set. When setted it does not build.

What cairo libs are needed?

[Sylvain Pasche (sylvain-pasche)]

Look for the CAIRO_VERSION variable in the configure.in file at the top of the source tree. For mozilla-central, that's Cairo 1.6 (http://mxr.mozilla.org/mozilla-central/source/configure.in#122).

If you have building issues, I suggest you comment in the mozilla.dev.builds newsgroup (http://groups.google.com/group/mozilla.dev.builds/topics for the Web interface). You should also provide the complete error message there.

[Tchraven (tchraven)]

I just ran into this as well, any progress being made on this?

[SelenIT (selenit)]

I found another opacity and anti-aliasing related artifact. When I use 'Arial Black' font (about 18px size) together with opacity less than 1.0, the text appears a bit thinner (as if it had smaller font-weight). With larger font size the visual difference becomes less. Without anti-aliasing the text rendering doesn't change because of the opacity, but with 'standard' anti-aliasing the similar artifact still appears (so it may be not only ClearType-related problem). I didn't investigate if this happens to other fonts yet.

[SelenIT (selenit)]

Created an attachment (id=392986)
Demo of anti-aliased 'Arial Black' font with opacity issue

[Gingerbreadguy (gingerbreadguy)]

Created an attachment (id=396127)
Buried story on Digg showing text with green halo

Burying stories on Digg.com displays the text with a sort of green halo around it.

Someone else has reported that this problem also occurs when deleting images on Flickr, and that it does not occur on Vista 32-bit (I am using Vista x64). The Mozillazine thread in question is http://forums.mozillazine.org/viewtopic.php?f=38&t=1414815

[Kayoss120 (kayoss120)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

when ClearType is enabled in Vista x64, Firefox 3.5.2 displays some font colors wrong when opacity is used.

forum thread discussing the problem:
http://forums.mozillazine.org/viewtopic.php?f=38&t=1414815

a somewhat similar old bug is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=363861

html page showing the problem:
https://bug363861.bugzilla.mozilla.org/attachment.cgi?id=321706

another screenshot showing the problem:
https://bug363861.bugzilla.mozilla.org/attachment.cgi?id=396127

Reproducible: Always

Steps to Reproduce:
1. enable ClearType in Vista x64
2. run Firefox 3.5.2
3. look at this page: https://bug363861.bugzilla.mozilla.org/attachment.cgi?id=321706
Actual Results:
font colors look messed up

Expected Results:
font colors should not look messed up

[Kayoss120 (kayoss120)]

With font smoothing disabled or set to Standard, the problem doesn't happen.

by the way, here's how to find the font smoothing options in vista:
control panel --> personalization --> window color and appearance --> open classic appearance properties for more color options --> click on "Effects"

[Zurtex (zurtex)]

*** Bug 457538 has been marked as a duplicate of this bug. ***

[Goran-baotic (goran-baotic)]

I'm not active in bugzilla community, so pardon me for dropping in.
I'd just like to point out the circumstances under which the bug occurs:

- *** 64-bit *** Windows Vista / 7
- ClearType set to ON

I didn't succeed in replicating the bug on 32-bit versions of Vista/7, even
with ClearType set to on, so I think it's a 64-bit problem. I haven't tested teh bug on XP/64-bit.

Green artifacts appear on text elements when opacity is set to less than 1
(.999 or less). Clearly visible on jQuery or similar JS fade in/out effects
that utilize fast changes to element opacity.

I'm also having issues with PNG rendering in Firefox 3.5.* when color
management is turned on. Setting "gfx.color_management.mode" to 0 fixes the
issue. This is also a bug that only occurs on 64-bit versions of Windows OS.

From my layman point of view, I suggest that something is generally wrong with text and image rendering on Firefox 3.* when using a 64-bit Windows Vista/7.

[Grant Abraham (gabraham)]

I can replicate this bug with the cut-off text (as per comment #1 from Ryan Rubley). I am running Windows 7 RC 32-bit (build 7100). I also was able to replicate it on Windows Vista 32-bit on the same machine. Cleartype is on in both cases.

[Googulator (netrolller-3d)]

We already know the cause of this bug (the alpha-mask is incorrect for sub-pixel antialiased text), just don't know how to fix it (i.e., what the correct alpha mask would be).

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

*** Bug 520400 has been marked as a duplicate of this bug. ***

[Wesley-johnston (wesley-johnston)]

(In reply to comment #37)
Have you tried doing an rgb->hsl conversion and using one of those numbers? I don't really understand what's going on there (pardon the bug spam if I'm way off track), but just glancing at the patch, it seems like lightness might be a better match.

[Ken-adcstudio (ken-adcstudio)]

It doesn't just effect opacity. Check out http://www.mobify.me/ for a real world example. The "Learn More" text has an opacity set for .9999, but the upper right hand "Sign-up" doesn't. Changing color to other then white (via firebug) helps. To see it even better, turn off backgrounds with firebug.

Using Vista 64 with ClearType, FF 3.5.5 and FF 3.6 beta.

[Ken-adcstudio (ken-adcstudio)]

I noticed that the growl like new mail notification on Thunderbird 3.0b4 has the strangely colored anti aliasing too.

[Serenity-katz (serenity-katz)]

I was going to submit for a new bug, but this is exactly the same thing here. Xft and Cairo color fringing has been a long standing problem, and David Turner (you know, Mr. Freetype) wrote a patch addressing it loooong time ago. Somehow the Freedesktop.org people just wouldn't accept it, then again they don't always make the best decisions when it comes to font rendering. However, since Mozilla by default uses embedded libcairo, I really don't see any reason the patch can't be applied when building. Turner patches can be found on his site at freetype:

http://david.freetype.org/lcd/

which will not work for current versions of Cairo now, but there's the ubuntu patch derived from it:

http://archive.ubuntu.com/ubuntu/pool/main/c/cairo/cairo_1.8.6-1ubuntu2.diff.gz

I also have my own version adapted from Turner's original patch that applies cleanly against cairo 1.8.* -- which is the sole reason I build Firefox from source on my laptop. It would be great if Mozilla can just apply this patch when building release binaries, as it would save a lot of eyesore for users.

[Mozilla-behdad (mozilla-behdad)]

Ubuntu patches cairo and fontconfig to use the newer FreeType subpixel filters, whereas upstream cairo doesn't (yet). The whole thing is very controversial since those filters are suspected to infringe patents in the US...

So, that's where the discrepancy comes from...

[Ken-adcstudio (ken-adcstudio)]

This build (http://www.osnews.com/comments/22543) of "Firefox 3.7 with built-in Direct2D acceleration" seems to have fixed the issue (uses different font renderer?). I was suspecting some sort of hex math rounding issue, or using the full number instead of each channel's number separately.

[Ken-adcstudio (ken-adcstudio)]

Please see Bug 512136 (https://bugzilla.mozilla.org/show_bug.cgi?id=512136)
for windows possible related bug, with a test for windows vista/7 with cleartype https://bug363861.bugzilla.mozilla.org/attachment.cgi?id=321706

[Sylvain Pasche (sylvain-pasche)]

*** This bug has been marked as a duplicate of bug 363861 ***

[Sylvain Pasche (sylvain-pasche)]

*** Bug 512136 has been marked as a duplicate of this bug. ***

[Sylvain Pasche (sylvain-pasche)]

(In reply to comment #15)
> Please see Bug 512136 (https://bugzilla.mozilla.org/show_bug.cgi?id=512136)
> for windows possible related bug, with a test for windows vista/7 with
> cleartype https://bug363861.bugzilla.mozilla.org/attachment.cgi?id=321706

That's bug 363861, which isn't related to this one.

[Ken-adcstudio (ken-adcstudio)]

the new DirectWrite backend in Cairo, and demonstrated in this build (http://www.basschouten.com/media/blogs/blog/warning.html) fixes the issue for me (on Vista x64).

[Serenity-katz (serenity-katz)]

> ... The whole thing is very controversial
> since those filters are suspected to infringe patents in the US...

But the specific patch mentioned doesn't directly do anything about glyphs. It only enables lcdfilter options if it's _already compiled_ into the system's FreeType libs; that is, any patent issue would lie not in cairo, but in the freetype binaries because the distribution or the user chose to enable patented features, so it shouldn't be a problem for Mozilla source to include that patch. Am I misunderstanding the situation here?

[Mozilla-behdad (mozilla-behdad)]

Can you require a freetype new enough to have that API? (I think they were introduced in 2.3.0). Or doing dlopen tricks again?

[Serenity-katz (serenity-katz)]

> Can you require a freetype new enough to have that API? (I think they were
> introduced in 2.3.0). Or doing dlopen tricks again?

Turner's first lcd patch was for cairo-1.0.4, which was what, 3 years ago? The patch I use was originally for cairo-1.2.4, also ancient. I'd think the lib version is a non-issue here.

[Mozilla-behdad (mozilla-behdad)]

However, I think it is, if the base system is still RHEL5.

[Serenity-katz (serenity-katz)]

RHEL5 itself has Cairo > 1.2.4 already, why would it be a problem?

[Mozilla-behdad (mozilla-behdad)]

I'm talking about FreeType version. Cairo doesn't matter since Mozilla ships its own cairo.

[Serenity-katz (serenity-katz)]

I meant to say, if the cairo version is recent enough, freetype is probably ok--which was not true. I compiled freetype-2.2.1 (that's what RHEL5 has I think), and patched cairo fails when linking against it. Bummer.

[Anders Kaseorg (andersk)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2pre) Gecko/20100121 Ubuntu/10.04 (lucid) Namoroka/3.6pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2pre) Gecko/20100121 Ubuntu/10.04 (lucid) Namoroka/3.6pre

I’m using Firefox 3.6 from the ubuntu-mozilla-daily PPA on Ubuntu lucid amd64. Today, subpixel fonts started displaying poorly in Firefox compared to every other application on the system. They are bordered in distracting red and blue color fringes, which typically result from poor subpixel filtering.

I believe the problem is with the in-source cairo bundled by Firefox. This is fixed for all other applications with Ubuntu’s cairo patch debian/patches/04_lcd_filter (see <https://bugs.freedesktop.org/show_bug.cgi?id=10301>). But ubuntu-mozilla-daily recently started configuring their packages with --disable-system-cairo, leading to this regression.

Reproducible: Always

firefox 3.6~hg20100120r33527+nobinonly-0ubuntu1~umd2 from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa, on lucid amd64 with all current updates.

[Marien Zwart (marienz)]

And this is not bug 458612 (that is: you tried with a ~/.fonts.conf as mentioned around bug 458612 comment 14)? See also bug 458612 comment 31 for a way to check for that issue.

If you are correct about the only relevant difference being the 04_lcd_filter patch isn't this a bug with the ubuntu-mozilla-daily ppa? That is: don't you just want them to apply that patch to mozilla's copy of cairo when building?

[Reed Loden (reed)]

Most likely a dupe of bug 458612 or bug 404637...

[Alexander Sack (asac)]

I don't think that this is caused by the lcd patch (alone).

Andres, can you check if firefox honours any of the settings you can change in the gnome fonts dialog wrt hinting, anti aliasing, subpixel rendering?

[Anders Kaseorg (andersk)]

The Smoothing control (None/Grayscale/Subpixel) and the Subpixel Order control (RGB/BGR/VRGB/VBGR) takes effect after a restart of Firefox (though in other applications it takes effect immediately). The Hinting control (None/Slight/Medium/Full) does not take effect in Firefox.

AFAIK there’s no GNOME control for the LCD filter.

[Anders Kaseorg (andersk)]

I am aware of bug 458612, but this isn’t the problem I’m reporting. Ubuntu’s /etc/fonts/conf.d/11-lcd-filter-lcddefault.conf sets the right LCD filter systemwide, and changing lcdfilter in ~/.fonts.conf affects other non-GNOME applications but not Firefox.

Bug 404637 does match my symptoms.

[Alexander Sack (asac)]

i debugged this issue a few month ago and from my understanding it has something to do that gtk+ using system cairo for the font settings initialization and stores the config in a struct that is then not seen by firefox cairo ... but thats just out of the top of my head. I will see if i find the place where this happened again ...

[Vish (vish)]

I'm facing the same problem on 32 bit too:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2)
Gecko/20100124 Ubuntu/10.04 (lucid) Firefox/3.6

[Kees Cook (kees)]

Binary package hint: firefox

Firefox 3.6's fonts are not rendering follow the system configurations. It's really ugly on my LCD. :)

[Kees Cook (kees)]

Here is the before and after. Notices all the subpixel shading and edges (blue and pink), wrong rendering widths, etc.

[Marc Deslauriers (mdeslaur)]

Yep, same here.

[Micah Gersten (micahg)]

Is this Bug #379761?

[Kees Cook (kees)]

I don't think it's the same bug -- that seems to show totally different fonts?

[Marc Deslauriers (mdeslaur)]

No, that's not the same bug. That bug is for firefox not using the system font settings. This bug is for a rendering issue.

So, It looks like firefox is being compiled with "--disable-system-cairo", even though the rules file is supposed to check for cairo 1.8.8, and use the system cairo.

Since the firefox cairo doesn't have the lcd filter patch, and the system cairo does, rendering is ugly.

[Marc Deslauriers (mdeslaur)]

Ah, we're not building with system cairo anymore because of "DEB_MIN_SYSDEPS ?= 1" in the rules file.

So, in order to fix this issue we need to either build with the system cairo, or to include the 04_lcd_filter.dpatch patch from the system cairo into the firefox package.

[Micah Gersten (micahg)]

Thanks for the updates, I'll have asac take a look.

[Yuri Khan (yurivkhan)]

Also affects ppa:mozillateam/firefox-stable and ppa:ubuntu-mozilla-daily/ppa.

[Alessandro Ghersi (alessandro-ghersi)]

Same problem here with Kubuntu Lucid

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100125 Ubuntu/10.04 (lucid) Firefox/3.6

[lunch (launch-mailinator-com)]

Please fix this bug, I am using Karmic and installed from the ppa:mozillateam/firefox-stable repository and fonts look less than ideal.

[Mingming Ren (portis25)]

People who are not patient for a fix in the repo can add my ppa.
ppa:portis25/test, currently only for lucid.

I did nothing but forced the option --enable-system-cairo.

[Tobias Wolf (towolf)]

That’s lcdlegacy in the screenshot. Ubuntu defaults to lcddefault.

[Artyom Smirnov (smirnoffjr)]

Same after installing FF 3.6 from ppa firefox-stable on karmic. After rebuilding package with forced --enable-system-cairo - all ok.

[Yura Tolstik (yltsrc)]

Please fix this bug as faster as possible.

[lunch (launch-mailinator-com)]

@ Mingming

Please do that for Karmic as well. Thank-you very much !!

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

*** Bug 541319 has been marked as a duplicate of this bug. ***

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

*** This bug has been marked as a duplicate of bug 404637 ***

[Mingming Ren (portis25)]

Done, I copied the packages to karmic.
You can try ppa:portis25/test.

[Marc Deslauriers (mdeslaur)]

Here is a debdiff to add lcd filtering to firefox's in-tree cairo.

Test packages with this patch are in my PPA:

https://launchpad.net/~mdeslaur/+archive/testing

[Dao (dao)]

This bug is about Windows only... there's no ClearType on Linux. Whoever's adding the links to launchpad, please stop it.

[Alexander Sack (asac)]

On Thu, Jan 28, 2010 at 12:26:54PM -0000, Mingming wrote:
>
> People who are not patient for a fix in the repo can add my ppa.
> ppa:portis25/test, currently only for lucid.
>
> I did nothing but forced the option --enable-system-cairo.
>

remember that you need to disable official branding when doing
unofficial builds like this ...

 - Alexander

[Mingming Ren (portis25)]

Thanks, I've removed it from my ppa. I think Marc's patch is better.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

(In reply to comment #51)
> This bug is about Windows only... there's no ClearType on Linux. Whoever's
> adding the links to launchpad, please stop it.

Apologies from Launchpad. There's an open bug for this and I just asked for the priority to be increased:
https://bugs.launchpad.net/malone/+bug/499113

[lunch (launch-mailinator-com)]

So whats happening ?? Is this going to be fixed or what ?? ..... from what I can read it only requires a simple rebuild of the package that is in the Official Firefox Stable PPA.

[Micah Gersten (micahg)]

I'm adding a target of Beta 1 here to insure we get this fixed before widespread adoption of Lucid.

[bdoe (bdoe-att)]

This is affecting me as well, to such a degree that viewing websites for more than a few minutes in FF3.6 actually strains and hurts my eyes! I am actually going to use Google Chrome until this is fixed.

This should be elevated to the highest severity possible. This may not be a showstopper as far as program stability goes; but it is a definite showstopper in that it can actually cause bodily injury trying to use it!

[Alexander Sack (asac)]

On Tue, Feb 02, 2010 at 06:58:55AM -0000, bdoe wrote:
> This is affecting me as well, to such a degree that viewing websites for
> more than a few minutes in FF3.6 actually strains and hurts my eyes! I
> am actually going to use Google Chrome until this is fixed.
>
> This should be elevated to the highest severity possible. This may not
> be a showstopper as far as program stability goes; but it is a definite
> showstopper in that it can actually cause bodily injury trying to use
> it!
>

This has highest priority ... but we prefer this getting fixed
upstream rather than running our own patches or even system cairo
again ... remember we are not even at alpha-3 ;) ... enjoy!

 - Alexander

[lunch (launch-mailinator-com)]

This is an absolute CRITICAL bug. PLEASE fix this IMMEDIATELY !! It is TRIVIAL to fix as shown by Mingming.

[Yuri Khan (yurivkhan)]

Alexander Sack wrote on 2010-02-04:
> This has highest priority ... but we prefer this getting fixed
> upstream rather than running our own patches or even system cairo
> again

What are the negative consequences of building with system cairo?

[Stream (stream)]

I think this is a bot, adding those urls in the WRONG place. Something have to be done about that in bugzilla.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

(In reply to comment #53)
> I think this is a bot, adding those urls in the WRONG place. Something have to
> be done about that in bugzilla.

As I said in comment #52, this is a Launchpad bug that's already open. It's adding matches anytime a bug # is mentioned in text.

[Alexander Sack (asac)]

On Sun, Feb 07, 2010 at 03:55:29PM -0000, Yuri Khan wrote:
> Alexander Sack wrote on 2010-02-04:
> > This has highest priority ... but we prefer this getting fixed
> > upstream rather than running our own patches or even system cairo
> > again
>
> What are the negative consequences of building with system cairo?
>

major potential issues with security updates ... up to the points
where we need to revert from system to non-system cairo in a security
update ... hence we must keep this visible and fix for real or get
mozilla to not bump cairo requirements in security updates.

 - Alexander

[Micah Gersten (micahg)]

Not affected

[Micah Gersten (micahg)]

Not affected at the moment

[Chris Johnston (cjohnston)]

The nominations may not be appropriate. Please investigate and fix as appropriate.

[Tom Jaeger (thjaeger)]

Alexander Sack wrote:
> On Sun, Feb 07, 2010 at 03:55:29PM -0000, Yuri Khan wrote:
>> Alexander Sack wrote on 2010-02-04:
>>> This has highest priority ... but we prefer this getting fixed
>>> upstream rather than running our own patches or even system cairo
>>> again
>> What are the negative consequences of building with system cairo?
>>
>
>
> major potential issues with security updates ... up to the points
> where we need to revert from system to non-system cairo in a security
> update ... hence we must keep this visible and fix for real or get
> mozilla to not bump cairo requirements in security updates.

I guess I don't really understand what you expect to happen between now
and beta1. The chances of an lcd filtering patch landing in cairo
master in this timeframe is minuscule and even if it did, there'd be
hardly enough time for testing. So we're limited to the patch that is
out there right now. I only see four options:

(1) --enable-system-cairo
(2) Get someone from mozilla to ack the patch that we've been shipping
in cairo for ages
(3) Take a page out of debian's book, apply the patch and just don't
call the browser firefox. This needs to be an option, otherwise we have
no leverage for (2). Or ship two versions of the browser, one that is
called firefox and looks like shit, and one that is called namoroka and
looks good.
(4) Do nothing, repeat the disaster that is bug #217908 and let people
deal with it in PPAs.

Whatever solution is adopted, it's better make the decision now than in
six weeks, in order to maximize testing exposure. Nothing is really
going to change between now and then.

[Harry (harry33)]

Alexander Sack,
What is the situation with Mozilla?
Are they working with this bug?

If this gets solved this way, it should be enough.
Testers, who want a quick solution may install the fully working packages from Marc Deslauriers PPA (#108).

[Alexander Sack (asac)]

Bug 404637 is not obviously a dupe of this one. that one is about the lcd patch; this one is also about gtk settings not being honoured at all for hinting.

[Ventnor-bugzilla (ventnor-bugzilla)]

Is the Ubuntu patch now included in upstream Cairo? If so, this will be fixed by bug 542605

[Ventnor-bugzilla (ventnor-bugzilla)]

And if not, you may want to talk to the owner of that bug to discuss possible inclusion.

[Alexander Sack (asac)]

michael, this bug is about gtksettings for hinting style is not honoured if you use --disable-system-cairo - we dont have a patch for that in ubuntu.

[Karlt (karlt)]

asac: are you sure you don't have fontconfig rules overriding the gtk settings?
(See bug 458612.)

[Harry (harry33)]

This is bug in mozilla. No solution yet.

https://bugzilla.mozilla.org/show_bug.cgi?id=541319

[Alexander Sack (asac)]

Karl, iirc that was fixed a while ago by a fontconfig cleanup. also iirc, it was an issue even when using system-cairo.

Also, afaict fontconfig should never win over gtk settings - and thats the behaviour you see on the rest of the desktop.

[Micah Gersten (micahg)]

That bug is being addressed in bug 512561.

On 02/10/2010 11:54 PM, Harry wrote:
> This is bug in mozilla. No solution yet.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=541319
>
>

[Harry (harry33)]

 The mozilla bug 541319 has been marked as a duplicate of the mozilla bug 404637,
which is the bug this one (512615) is assigned to (see above on top).
So here we have a full circle.
That suggests that this one (512615) is a duplicate of the bug 512561.

[Alexander Sack (asac)]

On Mon, Feb 08, 2010 at 07:03:39PM -0000, Tom Jaeger wrote:
> Alexander Sack wrote:
> > On Sun, Feb 07, 2010 at 03:55:29PM -0000, Yuri Khan wrote:
> >> Alexander Sack wrote on 2010-02-04:
> >>> This has highest priority ... but we prefer this getting fixed
> >>> upstream rather than running our own patches or even system cairo
> >>> again
> >> What are the negative consequences of building with system cairo?
> >>
> >
> >
> > major potential issues with security updates ... up to the points
> > where we need to revert from system to non-system cairo in a security
> > update ... hence we must keep this visible and fix for real or get
> > mozilla to not bump cairo requirements in security updates.
>
> I guess I don't really understand what you expect to happen between now
> and beta1. The chances of an lcd filtering patch landing in cairo
> master in this timeframe is minuscule and even if it did, there'd be
> hardly enough time for testing. So we're limited to the patch that is
> out there right now. I only see four options:

the lcd issue is not the main issue here. the upstrema bug link is
wrong. the main issue we need to first fix is to get ffox honour your
hinting style at all ... once that is done we can discuss details like
the lcd patch etc.

 - Alexander

[Karlt (karlt)]

(In reply to comment #15)
> Karl, iirc that was fixed a while ago by a fontconfig cleanup. also iirc, it
> was an issue even when using system-cairo.

Excellent. As you imply, if gtk settings are having an effect with system-cairo, they should be having an effect with tree-cairo. This is the code that pulls in GTK Settings:

http://hg.mozilla.org/releases/mozilla-1.9.2/file/b24909ba494f/gfx/thebes/src/gfxPangoFonts.cpp#l3145

Doing "call FcPatternPrint(aPattern)" before and after cairo_ft_font_options_substitute() may be enlightening.

[Tom Jaeger (thjaeger)]

Alexander Sack wrote:
>> I guess I don't really understand what you expect to happen between now
>> and beta1. The chances of an lcd filtering patch landing in cairo
>> master in this timeframe is minuscule and even if it did, there'd be
>> hardly enough time for testing. So we're limited to the patch that is
>> out there right now. I only see four options:
>
> the lcd issue is not the main issue here. the upstrema bug link is
> wrong. the main issue we need to first fix is to get ffox honour your
> hinting style at all ... once that is done we can discuss details like
> the lcd patch etc.

I fail to see how the two issues are related and why one needs to be
fixed before the other. I also think you have your priorities wrong:
This issue has already generated much more discussion than the hinting
style issue, which has been around since the jaunty release cycle (IIRC)
and has a fairly straightforward workaround in terms of messing with
/etc/fonts/conf.d.

[Alexander Sack (asac)]

On Thu, Feb 11, 2010 at 07:07:07PM -0000, Tom Jaeger wrote:
> Alexander Sack wrote:
> >> I guess I don't really understand what you expect to happen between now
> >> and beta1. The chances of an lcd filtering patch landing in cairo
> >> master in this timeframe is minuscule and even if it did, there'd be
> >> hardly enough time for testing. So we're limited to the patch that is
> >> out there right now. I only see four options:
> >
> > the lcd issue is not the main issue here. the upstrema bug link is
> > wrong. the main issue we need to first fix is to get ffox honour your
> > hinting style at all ... once that is done we can discuss details like
> > the lcd patch etc.
>
> I fail to see how the two issues are related and why one needs to be
> fixed before the other. I also think you have your priorities wrong:
> This issue has already generated much more discussion than the hinting
> style issue, which has been around since the jaunty release cycle (IIRC)
> and has a fairly straightforward workaround in terms of messing with
> /etc/fonts/conf.d.
>

The hinting style issue was around with upstream builds, but not with
our system-cairo builds.

 - Alexander

[Tom Jaeger (thjaeger)]

Alexander Sack wrote:
> On Thu, Feb 11, 2010 at 07:07:07PM -0000, Tom Jaeger wrote:
>> I fail to see how the two issues are related and why one needs to be
>> fixed before the other. I also think you have your priorities wrong:
>> This issue has already generated much more discussion than the hinting
>> style issue, which has been around since the jaunty release cycle (IIRC)
>> and has a fairly straightforward workaround in terms of messing with
>> /etc/fonts/conf.d.
>>
>
> The hinting style issue was around with upstream builds, but not with
> our system-cairo builds.

I was referring to bug #379761. How is bug #512561 different?

[lunch (launch-mailinator-com)]

Please fix this faster if possible.

[lunch (launch-mailinator-com)]

So this will NEVER get fixed ??

[Tom Jaeger (thjaeger)]

Martin, let me repeat my question from comment #126: Why not take care
of this now? What do you expect to happen between now and beta 2?

On 03/12/2010 09:03 AM, Martin Pitt wrote:
> ** Changed in: firefox (Ubuntu Lucid)
> Milestone: ubuntu-10.04-beta-1 => ubuntu-10.04-beta-2

[Keith Baker (keibak)]

Please build Firefox with system cairo.
The current version is unusable due to the broken font rendering. Building Firefox on one's own isn't easy as the mozilla build options aren't really self explaining.

BTW, Thunderbird 3 from mozilla-daily is also affected.

[Jud Craft (craftjml+ubuntulp)]

One possible user workaround is to just use grayscale smoothing, since this avoids the conundrum of cairo library LCD filter conflicts.

On a cross-distro note, Fedora ships with grayscale enabled by default, hence this flaw in a Fedora system would not be immediately apparent. In addition, they also disable LCD filtering [for other reasons], so their subpixel smoothing actually always looks this bad.

Another question might be, not why does Firefox ship its own cairo, but why do they use the worst filtering by default? If they enabled default filtering this bug might never have been noticed, as even experienced Ubuntu users only have seldom reasons to change their LCD filtering type.

[andrey i. mavlyanov (andrey-mavlyanov)]

> but why do they use the worst filtering by default?

because the fonts looks better with their libs on that settings. most of advanced users rebuild the font libraries or use it from russianfedora repositary or similar places

[Abhinay Mukunthan (lexxonnet)]

I've still got this issue with Lucid Beta1, just upgraded and got a shock when I started firefox. The fonts look absolutely awful, I hope there's an official fix soon, or I see this turning into a ppa-based fix-frenzy.

[Tom Jaeger (thjaeger)]

@asac:

Sorry it took me so long to reply, here's a little bit about the history of the patch.

The subpixel patch that ubuntu is currently using was added to cairo master during the 1.8.0 cycle, but then dropped shortly before the release [1], essentially because of concerns over the test suite failing on some systems. Ubuntu (and debian, I think) simply reverted the revert, and have been shipping the patch in their cairo ever since, without any issues that I know of. There have been several attempts to re-introduce the feature, the last one this January [2,3], but they have never resulted in a new patch, partly because it is not clear how upstream wants to solve this (Carl is quite unreasonable on this issue, in my opinion). See also the upstream bug.

The patch is very well-tested and the outcome is generally preferred to the legacy filter, so it's hard to imagine mozilla rejecting it.

[1] http://cgit.freedesktop.org/cairo/commit/?id=5d887ad5dca5af0f8216830d1b04d08a5aba9bee
[2] http://lists.cairographics.org/archives/cairo/2010-January/018778.html
[3] http://lists.cairographics.org/archives/cairo/2010-January/018870.html
[4] http://bugs.freedesktop.org/show_bug.cgi?id=10301

[Rob Roland (rob-roland)]

This should definitely apply to Thunderbird also - they both look awful. I want my subpixel rendering!

[bloo (bloo)]

As Rob Roland pointed out, it also affects Mozilla Thunderbird.

[bloo (bloo)]

Two comments point out that Mozilla Thunderbird is also affected, and I have verified and can confirm it too.

[Micah Gersten (micahg)]

Source package is thunderbird, not mozilla-thunderbird.

[Micah Gersten (micahg)]

Thunderbird is using system cairo, so I'm marking this invalid.

[bloo (bloo)]

@Micah,

UI fonts in both Firefox and Thunderbird look the same to me (as in "different than the rest of the system"). I (maybe wrongly) assumed that this was caused for the same reason as the problems in Firefox. Before I checked, with latest package in lucid as of today, Keith Baker and Rob Roland reported that Thunderbird 3 has the same problem.

Is there any other open bug where this has been reported? I am not the only user that thinks that Thunderbird may be affected, but I don't know if the cause is different.

[Micah Gersten (micahg)]

@bloo

Possibly bug 512561

On 04/01/2010 10:54 AM, bloo wrote:
> @Micah,
>
> UI fonts in both Firefox and Thunderbird look the same to me (as in
> "different than the rest of the system"). I (maybe wrongly) assumed that
> this was caused for the same reason as the problems in Firefox. Before I
> checked, with latest package in lucid as of today, Keith Baker and Rob
> Roland reported that Thunderbird 3 has the same problem.
>
> Is there any other open bug where this has been reported? I am not the
> only user that thinks that Thunderbird may be affected, but I don't know
> if the cause is different.
>
>

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 3.6.3+nobinonly-0ubuntu1

---------------
firefox (3.6.3+nobinonly-0ubuntu1) lucid; urgency=low

  * New upstream release v3.6.3 (FIREFOX_3_6_3_RELEASE)

  [ Jamie Strandboge <email address hidden> ]
  * AppArmor:
    - add leafpad and mousepad text editors for XFCE users (LP: #543587)

  [ Micah Gersten <email address hidden> ]
  * fix LP: #548866 - forgets middlemouse.contentLoadURL on upgrade; add patch
    from xulrunner-1.9.1
    - update debian/patches/series
    - add debian/patches/lp548866_bz467766_att351173-dont-reset-user-prefs-on-upgrade.patch

  [ Chris Coulson <email address hidden> ]
  * Add a cairo LCD filter to use Freetype LCD colour filtering features,
    based on the same patch applied to our system cairo package. Thanks to
    Marc Deslauriers for helping to make this work. (LP: #512615)
    - add debian/patches/lp512615_cairo_lcd_filter.patch
    - update debian/patches/series
  * Fix LP: #546490 - "Firefox will not start in debug mode"
    - update debian/firefox.sh.in
  * Fix a build issue installing ubuntu-abrowser.js when building with
    DEB_MIN_SYSDEPS=0
    - update debian/rules
 -- Chris Coulson <email address hidden> Fri, 02 Apr 2010 16:44:02 +0100

[Shiba (shiba89)]

Using Lucid Lynx amd64, fonts are now perfect. Thank you very much!

[Whitehat (i-whitehat)]

Lucid Lynx i386 - still have "fat" fonts after update to 3.6.3+nobinonly-0ubuntu1

[Whitehat (i-whitehat)]

screen... all fonts in thunderbird and firefox are "fat"

[Whitehat (i-whitehat)]

fixed by creating "~/.fonts.conf" file like in attachment

[Marc Deslauriers (mdeslaur)]

@Whitehat: your "fat fonts" bug isn't what this bug is about. That is bug #379761.

[Igron (igron)]

I have such image:
http://img405.imageshack.us/img405/5084/screenzi.png

Fonts are poor.

[Oli (oli)]

I suspect a lot of you upgraded. I've had this before in previous upgrade/downgrade issues where Firefox and Thunderbird skitz out and show horrible fonts. Thankfully the fix is stupidly simple:

sudo fc-cache -fv

Then kill off firefox/tbird and re-launch them. You'll have crisp, dainty fonts.

It always takes me about 12 hours to find that out each time I break my fonts. I should alias it.

[Karlt (karlt)]

*** Bug 581715 has been marked as a duplicate of this bug. ***

[Karlt (karlt)]

*** Bug 590864 has been marked as a duplicate of this bug. ***

[Karlt (karlt)]

*** Bug 541319 has been marked as a duplicate of this bug. ***

[Karlt (karlt)]

I think this should be fixed now, as of Bug 660448 landing, though most of the fix was in Bug 562746.