217313 - Mozilla misses bottommost pixels of characters sometimes when displaying text files

Status: NEW

(Core :: Layout, defect)

Description

[r.e.j.degroot]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030305
Build Identifier: ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.3/src/

When displaying large area's of text. Mozilla sometimes doesnt render the bottom
most pixels of characters. When the lines of text are selected with the mouse,
they do get rendered properly. This only seems to happen on Sun Solaris.

A sample snapshot of this can be found at: kryptology.org/example.tiff

Reproducible: Sometimes

Steps to Reproduce:
1. Start mozilla and open a website with large area's of text.
2. You might have to scroll a bit.
Actual Results:  
Misrendering of characters. See kryptology.org/example.tiff

Expected Results:  
Correct rendering of text characters.

Comment 1

[Kai de Leeuw]

Reporter, your build is very old. Please download a later version and try to
reproduce the problem in that version, and close this bug accordingly if you can't.

Comment 2

[dolphinling]

This is not sun-only, it happens on my Linux, too, and has with every version of
Mozilla I've had (including recent nightlies). I believe it is something to do
with the system fonts rather than Mozilla, though I'm not completely sure.

Comment 3

[Christian Hamacher]

Like Andrew, I have seen the same behavior for ages now, with every CVS build I
did, including yesterdays (I'm using Xft builds).

I have seen this go to extremes sometimes, when whole lines of text seemed to
have disappeared, only to reappear when highlighted.

I also believe there is a strong link to the font system: at home under Linux, I
have a bookmark for a site that regularly showed the 'missing line' problem - I
then, for another reason (see bug #183729), cleaned out my TTF font directory,
and reinstalled a different collection of TTF fonts. Instantly, the problem of
missing lines went away, while the problem of 'overlapping' lines, and thus rows
of missing pixels, is sometines still visible.

Also, while debugging the problem described in bug #183729, I temporarily
installed a non-Xft build, and didn't see the problem *at all* (neither missing
pixel rows due to overlap, nor missing lines).

BTW, I have never seen this problem on either Win98, WinNT 4.0 or Win2000.

Summary:
I believe the Problem is:
o Unix/Linux only
o linked to the font system (Problem in calculation of letter hights?)
o *maybe* connected to Xft? (do the SunOS release builds use Xft or similar?)

Comment 4

[r.e.j.degroot]

Solaris does not support Xft, therefor my mozilla builds are non-Xft. So it's
probably not Xft related.

Comment 5

[Christian Hamacher]

Re: comment #4:
Thanks for the feedback! Probably in my case, since switching to a non-Xft build
by definition leads to using a different font, the effect depended on the font
and not on the presence of Xft.

Here's the URL of one of the pages where I observed the missing lines - it's a
textual chapter from a web-comic (workplace-safe, unless you have a policy
against web comics :-):

http://www.everythingjake.com/d/20030710.html

As I wrote before, since I reorganized my TTF fonts I see neither missing lines
nor missing rows of pixels on this page - instead, I see placeholder characters
for apostrophes :-( But I still occasionally see the missing pixel rows on some
pages.

Comment 6

[Roland Mainz]

Reporter:
Can you please attach a screenshot (and mark (e.g. red circle around the part)
the corrupted parts using Gimp etc.), post the font path you are using and the
OS version ?

Comment 7

[Christian Hamacher]

Attachment: Corrupted fonts on www.mozilla.org

While I am not the original poster, I just had an example of the problem on my
screen when I read this comment, so here goes ...

This attachment shows a sections from the Mozilla webpage. Note the font
corruption in the words 'Created most weekdays' - but also note that the 'y' in
'weekdays' seems to have an intact downstroke.

This is a rather mild case of the problem - when I run across a better one, I
will post new screenshots.

I'm on RH 9 Linux, XFree 4.3, fontconfig 2.1, current Mozilla CVS build with
Xft.

My fontpath (from /etc/fonts/fonts.conf) is:

	<dir>/usr/share/fonts/default/TrueType</dir>
	<dir>/usr/share/fonts/default/Type1</dir>
	<dir>/usr/share/fonts/default/ghostscript</dir>
	<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
	<dir>/usr/X11R6/lib/X11/fonts/OTF</dir>
	<dir>/usr/X11R6/lib/X11/fonts/ttf</dir>
	<dir>/usr/local/share/fonts/TTF</dir>
	<dir>~/.fonts</dir>

Also see the next two attachments ...

Comment 8

[Christian Hamacher]

Attachment: Screenshot after highlighting word

Same region of screen, after I double-clicked on the word 'Created', and thus
highlighted it. When the highlight appears, the whole row of text slightly
shifts, and the font corruption disappears.

Comment 9

[Christian Hamacher]

Attachment: Inverse behavior: corrupted when highlighting

I'm not at all sure this is relevant, but anyway:

While looking for a nice example of this problem, I found the inverse behavior
on www.microsoft.com. The attachment shows a region of screen that is perfectly
intact (like the part under 'Get Help from ...'), *until* I highlight a section
of text (see highlighted passage: 'From installation ... Windows XP'). The
highlight shows a stronger (but not uncommonly so) manifestation of the
corruption that sometimes appears in un-highlighted text, where at least two
rows of pixels seem to be missing from the bottom of the row.

Comment 10

[Joosep-Georg Järvemaa]

This is dupe of bug #94739, I think...

Comment 11

[Christian Hamacher]

Over in bug 94739, a workaround was posted (look at comment 28 there). This
fixed the problem completely for me - if it also does for you (obviously, the
workaround only works for unixoid systems, since you need to modify your X
config), this is one more indication that this bug is a dupe.

Comment 12

[Christian Hamacher]

Confirming based on large number of duplicates, similar bug reports, and
comments in those.

See the meta bug 134942 with a long list of comparable '1-pixel-rounding' errors.

Platform->All
OS->All
Component->Layout

Comment 13

[Christopher Hoess (gone)]

Shouldn't this be duplicated into bug 94739, then?