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.

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.

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.

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

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

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.

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 ?

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

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.

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.

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

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.

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

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