fonts are incorrectly rendered due to not using system cairo

Bug #512615 reported by Kees Cook on 2010-01-26
610
This bug affects 119 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
Mozilla Thunderbird
Invalid
Undecided
Unassigned
SeaMonkey
Invalid
Undecided
Unassigned
eudora
Invalid
Undecided
Unassigned
firefox (Ubuntu)
High
Chris Coulson
Declined for Dapper by Loïc Minier
Declined for Hardy by Loïc Minier
Declined for Intrepid by Loïc Minier
Declined for Jaunty by Loïc Minier
Nominated for Karmic by Alexey Ten (Lynn)
Lucid
High
Chris Coulson
thunderbird (Ubuntu)
Undecided
Unassigned
Declined for Dapper by Loïc Minier
Declined for Hardy by Loïc Minier
Declined for Intrepid by Loïc Minier
Declined for Jaunty by Loïc Minier
Nominated for Karmic by Alexey Ten (Lynn)
Lucid
Undecided
Unassigned

Bug Description

Binary package hint: firefox

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

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.

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

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.

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.

Created an attachment (id=248910)
Testcase

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

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.

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

In , Dao (dao) wrote :

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

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

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

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

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

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

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

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.

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.

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

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

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.

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.

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

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.

In , Kliu (kliu) wrote :

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

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

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.

In , Kliu (kliu) wrote :

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

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

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

Rendered in Firefox 3 RC1 on Windows Vista.

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

Rendered in Firefox 3 RC1 on Windows Vista.

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

In , Kliu (kliu) wrote :

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

In , Kliu (kliu) wrote :

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

In , Kliu (kliu) wrote :

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

In , Kliu (kliu) wrote :

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

In , Kliu (kliu) wrote :

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

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

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

In , Kliu (kliu) wrote :

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?

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

In , Kliu (kliu) wrote :

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

Neither.

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

Changed in firefox (Ubuntu):
status: New → Confirmed
Micah Gersten (micahg) on 2010-01-26
summary: - fonts are incorrectly rendered
+ fonts are incorrectly rendered due to not using system cairo
Changed in firefox (Ubuntu Lucid):
assignee: nobody → Alexander Sack (asac)
importance: Undecided → High
status: Confirmed → Triaged
Changed in firefox:
status: Unknown → Confirmed
Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
Micah Gersten (micahg) on 2010-02-01
Changed in firefox (Ubuntu Lucid):
milestone: none → ubuntu-10.04-beta-1
Micah Gersten (micahg) on 2010-02-08
Changed in eudora:
status: New → Invalid
Changed in seamonkey:
status: New → Invalid
Changed in thunderbird:
status: New → Invalid
tags: added: patch
88 comments hidden view all 168 comments

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

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

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.

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

Harry (harry33) wrote :

This is bug in mozilla. No solution yet.

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

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.

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) wrote :

 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) wrote :

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

tags: removed: patch
tags: added: patch

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

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) wrote :

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) wrote :

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) wrote :

Please fix this faster if possible.

lunch (launch-mailinator-com) wrote :

So this will NEVER get fixed ??

tags: added: regression-potential
Martin Pitt (pitti) on 2010-03-12
Changed in firefox (Ubuntu Lucid):
milestone: ubuntu-10.04-beta-1 → ubuntu-10.04-beta-2
Tom Jaeger (thjaeger) wrote :

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) wrote :

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) wrote :

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.

> 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) wrote :

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) wrote :

@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) wrote :

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

Changed in firefox (Ubuntu Lucid):
assignee: Alexander Sack (asac) → Chris Coulson (chrisccoulson)
Martin Pitt (pitti) on 2010-04-01
Changed in firefox (Ubuntu Lucid):
status: Triaged → Fix Committed
bloo (bloo) wrote :

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

bloo (bloo) wrote :

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

Changed in mozilla-thunderbird (Ubuntu Lucid):
status: New → Confirmed
Micah Gersten (micahg) wrote :

Source package is thunderbird, not mozilla-thunderbird.

affects: mozilla-thunderbird (Ubuntu Lucid) → thunderbird (Ubuntu Lucid)
Micah Gersten (micahg) wrote :

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

Changed in thunderbird (Ubuntu Lucid):
status: Confirmed → Invalid
bloo (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.

Micah Gersten (micahg) wrote :

@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) wrote :

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

Changed in firefox (Ubuntu Lucid):
status: Fix Committed → Fix Released
Shiba (shiba89) wrote :

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

Whitehat (i-whitehat) wrote :

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

Whitehat (i-whitehat) wrote :

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

Whitehat (i-whitehat) wrote :

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

Marc Deslauriers (mdeslaur) wrote :

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

Igron (igron) wrote :

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

Fonts are poor.

Oli (oli) wrote :

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.

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

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

Changed in firefox:
importance: Unknown → Medium

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

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

Changed in firefox:
status: Confirmed → Fix Released
Displaying first 40 and last 40 comments. View all 168 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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