350111 - non-antialiased truetype fonts not rendered after the first space in a line

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Ilja Sekler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b2) Gecko/20060824 Firefox/2.0b2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060824 Minefield/3.0a1

Each text line is drawn only up to to the first space. The rest can be made temporarily visible either if marked with the mouse or redrawn by moving other windows above the Firefox window. The Firefox GUI and the web content are equally affected.

It happens if:

1. freetype2 is built with bytecode interpreter enabled (default on Ubuntu, Knoppix, SuSE 10.0/10.1)

2. antialiasing is disabled

3. Firefox or/and the desktop environment are configured to use truetype fonts.

It is a regression. The last "good" Build ID: 2006040604, the first "bad" Build ID: 2006040704.

Reproducible: Always

Steps to Reproduce:
1. Turn antialiasing off
2. Configure the desktop environment and Firefox to use truetype fonts
3. 

Actual Results:  
Text after the first space in each line is not rendered.

Expected Results:  
The Text should be completely visible.

Screenshots (sorry, I assumed mistakenly that this issue would be Bug 319867):
https://bugzilla.mozilla.org/attachment.cgi?id=234934
https://bugzilla.mozilla.org/attachment.cgi?id=234935

made on Fedora Core 5 with recompiled freetype-2.1.10-5.2.1. The partially invisible font: Arial.

Comment 1

[Ilja Sekler]

It is a cairo-gtk2 issue. Builds with --enable-default-toolkit=gtk2 are not affected. Changing the default toolkit on Linux to cairo-gtk2 (Bug 323925) has revealed the bug.

Comment 2

[Ilja Sekler]

Oops, sorry, didn't want to mark it fixed. Reopening.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

cworth mentioned a (fixed in upstream) cairo bug that would cause this the other day...

Comment 4

[Carl Worth]

(In reply to comment #3)
> cworth mentioned a (fixed in upstream) cairo bug that would cause this the
> other day...

Specifically, the upstream cairo bug report is here:

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

The fix is here:

http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=456cdb3058f3b416109a9600167cd8842300ae14;hp=8601c2c68306c956744399099a941363d446b906

And the fix exists in both the 1.2.2 and 1.2.4 releases of cairo.

Meanwhile, it's worth mentioning that the missing text is actually caused by a bug in some X servers. Cairo's "fix" is actually just a workaround to carefully avoid triggering that bug. The Xorg bug report for this issue is here:

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

-Carl

Comment 5

[Ilja Sekler]

(In reply to comment #4)
 
> The fix is here: [...]

I've built Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060830 Minefield/3.0a1, checkout start: Mi 30. Aug 19:15:20 CEST 2006, cairo-gtk2 with the patch and it fixes this problem as well as the whole bunch of similar issues like Bug 252033, Bug 319867, Bug 242698 etc. (my apologies for unqualified comments there) and text-select shifting of korean text for me, thanks a lot :-)

Any chance of backporting the fix for the 1.8 branch (cairo 1.0.2?)?
 
> And the fix exists in both the 1.2.2 and 1.2.4 releases of cairo.

As far as the impact on the usability of official nightly builds is so high, why not using the fix at least until the X server issue has been resolved?

Comment 6

[Carl Worth]

(In reply to comment #5)
> the patch and it fixes this problem as well as the whole bunch of similar
> issues like Bug 252033, Bug 319867, Bug 242698 etc. (my apologies for
> unqualified comments there) and text-select shifting of korean text for me,
> thanks a lot :-)

I'm glad you found that useful.

> Any chance of backporting the fix for the 1.8 branch (cairo 1.0.2?)?

Is 1.8 really using cairo 1.0.2? This particular bug shouldn't actually appear in cairo 1.0.2, but a similar problem was introduced in cairo 1.0.4. See my comment #41 on that bug report here:

https://bugs.freedesktop.org/show_bug.cgi?id=6617#c41

where I link to the fix we've applied to cairo's 1.0 branch. We could even do a 1.0.6 that would be basically 1.0.4 plus this one fix if that would help anybody.

But as I also mention there, I'm not aware of any compelling reason for anyone to stick to cairo's 1.0 series rather than just switching to the latest 1.2 release. Does mozilla have any such compelling reason?

> > And the fix exists in both the 1.2.2 and 1.2.4 releases of cairo.
> 
> As far as the impact on the usability of official nightly builds is so high,
> why not using the fix at least until the X server issue has been resolved?
 
Oh, the fix is very useful, and should definitely be used right away. Waiting for the X server to get fixed doesn't make any sense.

I would definitely like to see mozilla start to track improvements in cairo much more quickly than is currently happening. I don't know if there's anything I can do to help with that, but if there is, please let me know.

-Carl

Comment 7

[Ilja Sekler]

Sorry -- the patch does not fix Bug 252033 as it happens only on gtk2 builds and the patch doesn't have any influence on that (tested on trunk and on the 1.8 branch, the latter with cairo 1.0.4 release + a minor tweak of cairoint.h + patch from <https://bugs.freedesktop.org/show_bug.cgi?id=6617#c41>). My mistake.

Anyway, cairo-gtk2 trunk builds with the patch don't have the problem with truncated lines after a space if the CSS property "letter-spacing" is involved, that triggers the bug in gtk2 builds. Testcase: https://bugzilla.mozilla.org/attachment.cgi?id=225616

Comment 8

[Ilja Sekler]

Fixed by checkins in Bug 354388.