Created attachment 289559 [details]
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 attachment 289572 [details]
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
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:
Things are actually stalled upstream unfortunately. Ubuntu/Debian users are lucky because their cairo is patched against this bug.
*** Bug 436760 has been marked as a duplicate of this bug. ***
Changing summary to reflect the current manifestation of this bug.
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?
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.
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:
which will not work for current versions of Cairo now, but there's the ubuntu patch derived from it:
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.
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...
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
(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.
> ... 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?
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?
> 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.
However, I think it is, if the base system is still RHEL5.
RHEL5 itself has Cairo > 1.2.4 already, why would it be a problem?
I'm talking about FreeType version. Cairo doesn't matter since Mozilla ships its own cairo.
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.
*** Bug 541319 has been marked as a duplicate of this bug. ***
*** Bug 581715 has been marked as a duplicate of this bug. ***
*** Bug 590864 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.