224038 - inlined comments before non-Latin1 character make fonts go wonky?

Status: RESOLVED DUPLICATE of bug 190278

(Core Graveyard :: GFX: Gtk, defect)

Description

[Jamie Zawinski]

This is totally weird.  If the HTML contains a <!-- --> comment, followed by a
non-Latin1 character (in this case, Omega, &#937;) it causes the font of the
rest of the line to be messed up (blocky, as if anti-aliasing was turning into
thresholding or something.)  I'll attach a screen shot to show what I mean.

This is the test case:

     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.  <!-- --> &#937;
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.

     <p>
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.  &#937;
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.
     Test. Test. Test. Test. Test. Test. Test.

Note that the comment is necessary to cause this behavior!  Both the comment and
the character have to be there for it to happen.


Mozilla 1.4
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701
Red Hat Linux release 9 (Shrike)
Linux 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686 athlon i386 GNU/Linux

Comment 1

[Jamie Zawinski]

Attachment: screen shot of the bug

Here's what it looks like.  The same glitch happens even when I use Text Zoom:
the font size changes, but the middle line still renders weirdly.

Comment 2

[Hixie (not reading bugmail)]

Weird. Can't reproduce this on a recent Windows build.

Can you try a more recent build (there have been a _lot_ of font changes since 
July) and if it still occurs, include the contents of about:buildconfig in this 
bug report? Thanks!

Comment 3

[Boris Zbarsky [:bzbarsky]]

Almost certainly an xft issue... If this is an --enable-xft build, please
reassign to the "GFX: Gtk" component.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: testcase

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

->Gtk (Xft)

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This reminds me a little bit of bug 190278 (which is an Xft bug), but I don't
think it's the same thing.

Comment 7

[Jungshik Shin]

I don't see any difference between two cases on linux-Xft 1.5. Can somebody
attach a scrreenshot with a clearer difference? 

Comment 8

[Jamie Zawinski]

Zoom in...

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Look at the text on the third line of each half, following the Omega.  In the
first half the text is not antialiased, but in the second half it is.

Comment 10

[Jungshik Shin]

OK. I see the difference in attachment 134383 [details], but with mozilla 1.5 (gtk2+xft)
and libXft (cvs snapshot of early October), I can't reproduce the bug with
various fonts.

jwz, do you still have a problem with a recent build? 
 

Comment 11

[Christopher Blizzard (:blizzard)]

On my RH9 system, this definitely triggers bug 190278, so I'm guessing that's
what is causing the change in fonts.  The change is random, and sometimes points
to garbage so it might just end up choosing another font.

I can't reproduce on my Fedora Core system at all.

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