87738 - Fonts look jagged sometimes, highlighting (selecting) text fixes them

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Text, defect)

Description

[Francisco León]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010623
BuildID:    2001062306

Some strange behaviour when displaying fonts. Happens most frequently with thin
fonts like abobe courier. In all parts of mozilla, sometimes the text look
jagged and highlighting the text fixes it. Scrolling up and down the text is a
good way to "break" the fonts so they look jagged. Happens on other fonts too.
Also, when writing mail and scrolling between lines of text, sometimes they get
broken in half and even get the window all dirty. Again, highlighting the text
fixes this

Reproducible: Sometimes
Steps to Reproduce:
1.Just browse, and watch out for the text. Do a lot of scrolling to "help" the
bug to show up
2.See the problems in font rendering
3.Highlight the text 

Actual Results:  Fonts look ugly. Highlighting the text fixes it

Expected Results:  Fonts should always be clean

Attaching 2 screenshots that shows up both issues (dirty window, bad font rendering)
Why this should be a "minor" bug, it's really a bother

Comment 1

[Francisco León]

See attachment 40015 [details] and attachment 40016 [details] for a before-and-after look
This is catfood to me
See bug 87055 for more info. 87055 depends on this one?

Comment 2

[Francisco León]

In those 2 screenshots, take a look at this
On the first one: all words with a letter that goes down (like g and p) looks
broken.
Between that first line and the second they are 2 black spots of old text that
was there and got deleted. The window remains dirty
Then watch the straight line. Looks like a drunk person drawed it.
After highlighting the text with the mouse, it cleans out to look like the
second screenshot

Comment 3

[R.K.Aa.]

I use adobe courier for monospace fonts, and don't see the bug you describe.
WFM, using XFree86 4.0.3 w/xfs.

Please add info about your Linux distribution, X-server and fontserver version,
font size setup and resolution in Mozilla, as well as X resolution and preferred
fontsize. Furthermore: Are you using ISO8859-1 charset or other?

Comment 4

[Francisco León]

see attachment 39979 [details] to see what fonts are being loaded
Mandrake 8, Xfree 4.0.3, 
 FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
    FontPath   "unix/:-1" is on my XF86Config file

adobe courier is at size 16, proportional is set to serif, size 18
:0 local /usr/X11R6/bin/X -deferglyphs 16 -nolisten tcp -dpi 100 is on my
xserver's settings

that deferglyhps line looks suspicious... i will remove it

Comment 5

[Francisco León]

Just deactived the glyph 16 thing. Same jag, but seems less frequent now. Was i
instructing X to deglyph when font size was 16? This sounds logical. But why
this wasn't an issue with older builds?

Found another way to reproduce. The commit button here on bugzilla looks jagged
by default, clicking and releasing fixes it, then clicking and holding the
button down shows the button jagged (gimp has problems to make screenshots
holding down the button)

Anyway, i will be playing with this for a while. If i find a big jagged text i
will get a screen up

Comment 6

[R.K.Aa.]

I believe "deferglyphs = 16" is used for "lazy loading" of 16-bit fonts (like
asian fonts) so that shouldn't be the culprit.

The RH setup obviously differs from Mandrake's. RH uses a file
/etc/X11/fs/config to set up most font related stuff, not the XF86Config-4 file.

My own setup in /etc/X11/fs/config looks like this:

client-limit = 10
clone-self = on
catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled,
	/usr/X11R6/lib/X11/fonts/75dpi:unscaled,
	/usr/X11R6/lib/X11/fonts/100dpi:unscaled,
	/usr/X11R6/lib/X11/fonts/misc,
	/usr/X11R6/lib/X11/fonts/Type1,
	/usr/X11R6/lib/X11/fonts/Speedo,
	/usr/X11R6/lib/X11/fonts/TrueType,
	/usr/X11R6/lib/X11/fonts/75dpi,
	/usr/X11R6/lib/X11/fonts/100dpi,
	/usr/share/fonts/default/Type1,
	/usr/share/AbiSuite/fonts,
	/usr/share/fonts/ja/TrueType

default-point-size = 120
default-resolutions = 75,75,100,100
deferglyphs = 16
use-syslog = on
no-listen = tcp


--------

Are you sure you updated the font rpm's when you installed XFree86 4.0.3?

I too use adobe courier as monospace font, but i use MS Arial for both serif and
sans serif font, and thus see the Arial font-face on the Commit button.

For fun: Attaching screenshot (excerpt) of this page with fonts blown up to
200%. That is Adobe Courier as monospace font, rendered by XFree86-xfs 4.0.3
(and Arial for serif/sans-serif fonts).

Comment 7

[R.K.Aa.]

Attachment: 200% zoom on a RH7.1w/xfs, XFree86 4.0.3 and 72dpi fonts as default

Comment 8

[kill this account]

Could you specify what exactly in the attachment looks wrong?

It would help if you could attach a xmag of one the jaggy glyphs.

Could you also display the page with NS_FONT_DEBUG=9 and attach the output?
eg: ./mozilla http://www.somesys.com/somepage.html

Could you attach a xmag of the glyph displayed via xfd of what you expect to 
be the correct glyph?

(I'm not trying to make it so hard you give up, so please do not give up. 
I'm trying to get enough information to figure out what is happening.)

Comment 9

[kill this account]

Attachment: xmag of attachment 40047

Comment 10

[kill this account]

oops, the attachment is a xmag of 40015 not 40047

Comment 11

[kill this account]

> gimp has problems to make screenshots holding down the button

one way to get an image of a pressed button is to have a short delay before
xwd -id <window id>

1) use xwininfo to get the window id of the commit button

2) sleep 5; xwd -id <window id> > junk.xwd

3) in the 5 second delay press the commit button

4) use gimp / xwud to display the image

5) use xmag to get a magnified version

6) use gimp to convert to PNG

Comment 12

[Francisco León]

dark's attachment looks exactly like 0.9.1 looks for me
Since xfree 4.0.3 comes with mandrake, i didn't have to update the font list
The main question to ask here is: why does 0.9.1 work ok for me and 0.9.1+ does
not? Without changing anything on my system.
Dark: the mandrake files for xfs are exactly handled in the same way. XF86Config
file only comes set up to load the xfs font list
FontPath   "unix/:-1" is on my XF86Config file

But i also have your fs/config file and it looks like this:
catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled,
        /usr/X11R6/lib/X11/fonts/75dpi:unscaled,
        /usr/X11R6/lib/X11/fonts/100dpi:unscaled,
        /usr/X11R6/lib/X11/fonts/Type1,
        /usr/X11R6/lib/X11/fonts/Speedo,
        /usr/X11R6/lib/X11/fonts/mdk:unscaled,
        /usr/X11R6/lib/X11/fonts/mozilla-fonts,
        /usr/X11R6/lib/X11/fonts/drakfont,
        /usr/X11R6/lib/X11/fonts/pcf_drakfont:unscaled,
        /usr/share/fonts/default/Type1,
        /usr/share/fonts/ttf/decoratives,
        /usr/share/fonts/ttf/western

Both our files are wrong :) 100 dpi fonts should get loaded before 75 one, and
late on the list there is mention to mozilla fonts and even ttf fonts, so i will
try moving up the order. Still, like i said, paid attention to this:
Mozilla looks good on 0.9.1, not on 0.9.1+ without touching my computer's config.
Like i said on the other bug, i used  0.9.1's unix.js file and put it in the
newer 0.9.1+ dir. It does _not_ fix the problem for me

Comment 13

[Francisco León]

Attachment: Debug output requested

Comment 14

[Francisco León]

Attachment: Commit button after being clicked (left) and being clicked (right)

Comment 15

[kill this account]

from bug 87055

------ Additional Comments From Francisco León 2001-06-26 14:10 -------

... I must also say that the commit button looks jagged
in 0.9.1 too, until i click it, as i exposed in attachment 40082 [details]

Comment 16

[kill this account]

I looked at the glyphs in the list of loaded fonts and
the glyphs look like either one of these:

 -Adobe-Times-Medium-R-Normal-18-180-75-75-P-94-ISO8859-1
 -adobe-times-medium-r-normal-19-140-100-100-p-95-iso8859-1

None of the other fonts are close.

Rather than a font problem it looks to me that there is a one pixel 
"left shift of the top 7 pixels".

This looks like a layout problem to me (and it is seen before my latest
font changes) so back to karnaze.

Comment 17

[kill this account]

re-assign to karnaze

Comment 18

[Francisco León]

*** Bug 88406 has been marked as a duplicate of this bug. ***

Comment 19

[Francisco León]

*** Bug 80668 has been marked as a duplicate of this bug. ***

Comment 20

[Francisco León]

This has gotten worse in recent builds. Increasing severity.
When highlighting text and delete it in mail, all mail text gets erased from the
screen, and when highlighting the rest of mail, it appears again.

Screenshots coming...

Comment 21

[Francisco León]

Attachment: I highlight the text i want to delete

Comment 22

[Francisco León]

Attachment: I scroll up a little, notice the missing text

Comment 23

[Francisco León]

Attachment: I highlight the paragraph with the problem. See the text reappear!

Comment 24

[Francisco León]

Literally, text gets cut , but it does not happen by just scrolling, you need to
delete some text in mail, so the text "reubicates" itself, and when it does, the
text dissapears.

Comment 25

[kill this account]

Francisco: would you try turning off your font server and see if that
has any effect?

Comment 26

[kill this account]

Francisco: is this a different issue than the one reported in bug 95280?

I suspect that since this seems to occur with scaled fonts and not occur
with non-scaled fonts that this is a server side problem. However, until
we understand the problem it does not make sense to apply a fix.

Comment 27

[Francisco León]

Since i have my font.scale settings in size 20 and i am using lower sizes,
wouldn't that mean i have font scaling disabled?
So that would mean an issue not related to that bug you mentioned. It's part of
this one (jagging)

Disabling my xfs server would require some changes around here... I will try it asap

Comment 28

[Francisco León]

Ok, i killed my font server
Monospace font looks beautiful, attaching screenshot... However, when i select
the text, erase it, and scroll up the text dissapears until i highlight it again...

Comment 29

[Francisco León]

Attachment: How monospace font looks without XFS

Comment 30

[Francisco León]

So i think this establishes that it's not a font problem, but a layout problem
caused by mozilla getting the fonts dirty when it tries to push text lines up or
down when scrolling or deleting text.
When scaling fonts, all lines disappear but the first or last one, that one
looks jagged.
When not scaling fonts, all lineas disappear.

There are tons of bugs caused by text positioning or scrolling.

Comment 31

[karnaze (gone)]

-->ftang

Comment 32

[R.K.Aa.]

*** Bug 125810 has been marked as a duplicate of this bug. ***

Comment 33

[R.K.Aa.]

*** Bug 123811 has been marked as a duplicate of this bug. ***

Comment 34

[Jeremy M. Dolan]

Does this also cover the case of a line not being jagged at all, but shifting
anyway? On this page:

http://www.usdoj.gov/atr/cases/ms_tuncom/major/mtc-00027626.htm

The top line shifts 1 px right when I select any of it. Reload shifts it back
left. Most of the paragraphs as well shift the whole line of text as soon as
it's highlighted.

But this is quite differant from the 'jagged' font when scrolling thing, at
least in apperance. I don't have to scroll at all for the above to happen, and
the font is never jagged, the whole letter, from top to bottom, just shifts.

Are they both covered here?

Comment 35

[Francisco León]

being the bug reporter, that behaviour you describe is covered in this bug

Comment 36

[kill this account]

Jeremey: This bug is about part of the text pixels (eg: the upper half of a
line) being shifted relative to another part (eg: the lower half of a line).

Does the text unshift when you unhighlight it?

Comment 37

[Mark Purtill]

I'm having this exact problem with Windows 2000, Mozilla build 2002020406.  When
I go to the web page mentioned in an earlier comment,

http://www.usdoj.gov/atr/cases/ms_tuncom/major/mtc-00027626.htm

if I scroll down with the down arrow three times, then up arrow three times, I
always got the offset text (the top few pixels are offset to the left one pixel;
the break corresponds to a place where the screen was scrolled to between down
arrows).

Some additional possibly useful information:  I have my monitor set to
1200x1600, so I use large fonts.  I see this when I set the font size to 12, 16,
or 24 pixels, but not when it's set to 9 pixels.  I have this in my users.js file:

user_pref("font.minimum-size.x-western", 20);

Comment 38

[kill this account]

bug 112673 is probably a dup

Comment 39

[kill this account]

Mark: does it matter which font you select?

Comment 40

[Mark Purtill]

I tried several fonts, and all seemed to give the problem, including Times New
Roman.  However, it seems very sensitive to window size: when I made my window
full screen, the bug goes away on the DOJ page, though I got it on other pages, e.g.

http://nice.purrsia.com/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=23&t=001885&p=6

(On that page, as I move thru the page with up and down arrows, something like 1
line in 100 gets munged.)  Also, when I turned back on "Allow documents to use
other fonts", I didn't have the problem until I resized the window a little, and
then it came back.

BTW, this is the bug keeping me from using Mozilla on Windows.

Comment 41

[Sitsofe Wheeler]

I'm unsure what this bug is meant to now capture due to all the additional
comments. Is it
a) When scrolling the page text is offset causing it to become jagged
b) When scrolling parts of the text disappear completely

Either way, can the reporter (Francisco León) confirm that the bug(s) reported
are still happening in a recent nightly build. It would also be helpful if the
resolution of X (which can be found by doing xdpyinfo | grep reso) and the DPI
of Mozilla (Preferences -> Fonts -> Display resolution) could also be added to
if it still occurs. If the bug(s) no longer occur please can the reporter
resolve it WORKSFORME.

Comment 42

[Jimmy Sieben]

I see this bug all the time on Windows. I don't think it is an X-specific problem.

See <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=138521">Bug #138521</a>
for a description and a screen shot.

Comment 43

[Francisco León]

the bug still happens. Using all standard dpi settings (72dpi for the server, 
96dpi for mozilla) on rc1

i am trying a hacked freetype lib with hinting, i will post later with my 
results

Comment 44

[Francisco León]

what a difference... Now i am using 92x92 dpi (weird dpi settings) with
96 dpi in mozilla, and using a freetype hack found in
http://pclinuxonline.com/modules.php?name=News&file=article&sid=1928,
using the freetype rpms for mandrake 8.2 found on that webpage

My problems are gone with any font. However, surfing at pclinuxonline is
reaaally  slow because the freetype library impacts performance.

The windows user can try enabling "smooth fonts" in his display settings to see
if ./ improves

Comment 45

[Jimmy Sieben]

I have smooth fonts enabled, and the bug still happens on RC1.

Note that is not just /. that triggers the bug - it can be seen on any page. If
I scroll around, the text will become "broken".

Comment 46

[Kolja Kress]

Attachment: Where-does-it-come-from-screenshot

Comment 47

[Kolja Kress]

Attachment: Where-does-it-come-from-screenshot

Comment 48

[Kolja Kress]

Attachment: Where-does-it-come-from-screenshot

Comment 49

[Sitsofe Wheeler]

This looks like it could well be related to bug 120918. Francisco León did you
restart mozilla after you changed the font size in it to 96dpi when you were
running X at 72dpi? If not can you test at 72dpi again (with moz set to 96dpi)
and report back?

Comment 50

[Francisco León]

yes i did restart. i am no longer able to reproduce this at any mozilla dpi
setting. I must remind you that i am no longer using a "default" rc1 mozilla
since i did the changes proposed in the pclinuxonline url i gave earlier.

Comment 51

[kill this account]

Has anyone seen this problem in a post bug 120918 fix (after 2002-04-12) build?

This bug seems to be cross platform and it seems to be something like 
a math rounding error since changing DPI seems to affect it.

If I had to guess I'd say bug 120918 looks like a it could be related since it
is in cross platform code and changes the rounding of x/y for redraw.

Comment 52

[Sitsofe Wheeler]

Francisco, which build of mozilla are you using?

Comment 53

[Mark Purtill]

Yes, I'm still having the problem with the 2002042403 build (on Windows 2000).

Comment 54

[Francisco León]

rc1, whatever build that is (i'm not near my moz computer) gotten from 
pclinuxonline.com as rpm

Comment 55

[Ilya Konstantinov]

Still there, with RC3 on Linux with Freetype disabled.

Comment 56

[kill this account]

We know we have a layout problem; see bug 80530 and bug 134942.
I have a strong feeling this is a symptom of that layout bug.

Comment 57

[Rich Griswold]

I'm seeing the same problem with Mozilla 1.1a on both x86 Linux and SPARC
Solaris.  I've seen it with older versions of Mozilla as well.  I haven't
changed the font preferences, so Mozilla is using the default font.  

Here's the Solaris info:

  Resolution:        1152x900x24
  OS version:        Solaris 8
  Mozilla build ID:  2002061401
  Font path:         /usr/openwin/lib/X11/fonts/F3/
                     /usr/openwin/lib/X11/fonts/F3bitmaps/
                     /usr/openwin/lib/X11/fonts/Type1/
                     /usr/openwin/lib/X11/fonts/Speedo/
                     /usr/openwin/lib/X11/fonts/misc/
                     /usr/openwin/lib/X11/fonts/75dpi/
                     /usr/openwin/lib/X11/fonts/100dpi/

Comment 58

[Chris Elmquist]

I too experience the mangled fonts when scrolling a page.  It
appears as though the entire font is not being rendered as the
page is scrolled.  If I stop scrolling and reload the page, the
font is redrawn correctly.  If I begin scrolling again, some number
of lines later, pixels will again not be rendered.  My experience
is that an entire scanline of pixels is not rendered so the font
looks compressed (vertically) or chopped in height.

I see this on a stock RH7.2 installation with Mozilla build ID: 2002060511

Comment 59

[Bill Shannon]

I'm seeing this same problem on Solaris 8 SPARC with Mozilla 1.1.
When scrolling, it appears that a row of pixels disappears out of the middle
of a row of text.  Partially covering the window with another window and
then uncovering it causes the covered text to be redisplayed properly.
It's clear that the pixels are missing from the text, not from the entire
page.  I'll add an attachment showing the missing pixels.  The problem
occurs on many different web pages.

I'm using the default Mozilla fonts except for using Lucida Sans Typewriter
for Monospace.  I'm using the default Solaris font path.

Comment 60

[Bill Shannon]

Attachment: Missing pixels in next to last line of text

Comment 61

[Daniel Perup]

This bug seems closly related to bug 94739, which is bothering me a lot. It
still occurs frequently in Moz 1.2 beta, and significantly reduces readability
om lots of pages.

Comment 62

[kill this account]

This bug has been around a really long time, reported in various ways, and on
many platforms (except Mac to my knowledge).

This may be a shot in the dark but could this be an issue with the off screen
rendering not being correctly blitted to the screen?

Pav: could you comment on this?

Comment 63

[kill this account]

There is really no way for the font code to generate fonts where some of the 
glyphs in a line have the pixels shifted. In X the app does not actually handle 
the glyphs' pixels, the X server does. Specifically, 
http://bugzilla.mozilla.org/attachment.cgi?id=99448&action=view
"Missing pixels in next to last line of text" cannot be generated by moz's *font*
code. 

However, to hide the building of the display image, moz renders to an off screen
window then blits the final result pixels to the display. This could cause pixels
to be lost if the source or destination location was off by one.

Could someone who can reproduce this try setting the double buffering pref to 
false and see if it "fixes" this problem?

  pref("viewmanager.do_doublebuffering", true);

Comment 64

[Mark Thorp Duxbury]

>Could someone who can reproduce this try setting the double buffering pref to>false and see if it "fixes" this problem?It does not.If it at all helps, I am using:   x86 Linux (2.4.19)   XFree86-4.2.0   egcs-2.91.66   glibc-2.1.3

Comment 65

[Christopher Curzio]

I've started seeing this bug again as of 2003032108.

See the USDOJ example provided earlier. 

Comment 66

[Hans-Peter Keck]

Attachment: HTML file to reproduce the problem

I am seeing this bug, too. I am using Mozilla 1.3 on Linux 2.4.18 (Red Hat
7.3). I can reproduce the problem using the attached scrolltest.html file. It
contains several paragraphs of text with a different line height definition. I
just load it into Mozilla (make the window small enough to have something to
scroll) and position it such that only the upper half of the text line at the
bottom is visible. Then I click on the "down" arrow of the scrollbar to scroll
down one line. It turns out that the bug occurs only if an odd line hight is
defined for that paragraph.

Comment 67

[Hans-Peter Keck]

Is anything going to happen to fix this bug? I find it really very annoying.
BTW, I found out that it is present in the Galeon browser, too. This browser is
based on Mozilla. On the other hand, if I use any other web browser (like
konquerer, opera), I don't have such problems. This convinces me that it has
nothing to do with the X server. I think it's just a bug in the Mozilla
rendering engine when calculating text positions during scrolling.

Comment 68

[Hans-Peter Keck]

Attachment: comparison of normal vs. jagged fonts (magnified screenshots)

In order to further analyse the problem I have prepared this GIF. It is a
combination of two mozilla screenshots showing the same document (actually a
part of the HTML which I attached earlier), one with jagged fonts and the other
one with the correct ones. The left side shows the jagged fonts, the right side
the normal ones. I put a vertical on the edge between these two areas to make
it more visible.

I didn't scroll the upper two lines before making the screenshot, so there are
no jagged characters even on the left side. But for the others, you can see
that the characters are not only corrupted, but also in the wrong position (one
pixel too high).

I think this is the root cause of the problem. When scrolling, sometimes only
the upper or lower half of a text line is visible on the screen. Eventually,
the other half will become visible, too. If Mozilla calculates wrong positions
for some of these partial text lines, you have a good chance of seeing these
jagged characters, because the positions of the different parts don't match.

Comment 69

[Jeremy M. Dolan]

*** Bug 135012 has been marked as a duplicate of this bug. ***

Comment 70

[Evgueni Astigeevich]

The bug is still reproducible with Mozilla 1.6 on Solaris 9 SPARC (version 4/03)
with GNOME2.

Mozilla 1.6 was built in the following configuration:

--enable-default-toolkit=gtk2 --disable-ldap --enable-crypto --disable-mathml
--disable-tests --disable-debug --enable-js-ultrasparc

Comment 71

[Asa Dotzler [:asa]]

*** Bug 229894 has been marked as a duplicate of this bug. ***

Comment 72

[Hilbert Schraal]

Bug is reproduceable with FiroFox 0.8 on Linux/kde3.1

Comment 73

[Max Gilead]

I can reproduce this bug with Mozilla nightly 2004061508 and I was also
experiencing this bug for as long as I remember.

For me the problem appears in lines which were at the bottom of the window when
page was scrolled up. It disappears after display is refreshed for any reason -
switching windows, switching desktops, selecting and de-selecting text - all
these make problem disappear. However when browsing the web such ugly fonts can
be really problematic as they make reading quite difficult.

This problem is reproducible both with smooth scrolling enabled and disabled
however positioning of garbled lines vary in each mode. Without smooth scrolling
enabled garbled lines are away from each other while with smooth scrolling
enabled they are close. Attaching screenshots (I marked some garbled lines with
red dots).


As a side note, the problem with making screenshots with GIMP is that the
problem disappears after window refresh - I suggest setting a timeout of 10 to
20 seconds in GIMP, launching screenhot capturing, switching to Mozilla, making
it display fonts badly and then waiting for the screen capture to be activated.

Comment 74

[Max Gilead]

Attachment: Screenshot without smooth scrolling

Screenshot of URL http://www.cio.com/archive/061504/itwork.html with smooth
scrolling disabled; garbled lines close to each other.

Comment 75

[Max Gilead]

Attachment: Screenshot without smooth scrolling

Screenshot of URL http://www.cio.com/archive/061504/itwork.html with smooth
scrolling disabled; garbled lines separated by several lines.

Comment 76

[Max Gilead]

Attachment: Screenshot with smooth scrolling.

Screenshot of URL http://www.cio.com/archive/061504/itwork.html with smooth
scrolling enabled; garbled lines close to each other.

Comment 77

[Charlie Biemiller]

I noticed something else that may help is resolving this issue. The distored
fonts also happens outside of the browser's web page window. For example the
Find bar at the bottom of the window. My panel on KDE is set to hide and I
noticed that the "Find:" text label is not redrawn correctly all the time when
the panel hides. You can notice this also by dragging a smaller window over the
"Find:" text. If you try enough by dragging another window half over the "Find:"
text you can get "Fi" on one line and "nd:" about 2 pixels above it.

I can also get the "Look in" drop box in the "Save Link As" dialog box to do
this also.

To make a long story short I think the problem may be in the toolkit (GTK?)
instead of the code used to render web pages. I am using version 1.0 with Linux.

Hope this helps.

Comment 78

[Adam Hauner]

-> to default owner

Comment 79

[Andy]

Attachment: Defect Example Screenshot

As you can see, the text on the right side of these two paragraph tags becomes jagged and bold when hovering over a navigation element on the page.

Comment 80

[Guenter Lanz]

I have (with some initial trouble) managed to install 2.0.0.6 and now face all overtyped lines - in every second line. Hiliting makes the content IN SOME CASES readible, in others its content is not readible. I have not changed anything from my previous Thunderbird setup, I am not a system expert and hope you can  give me a simple-to-do solution.... I can show you a screen shot of one of my notes lists which shows the problem... HELP... G.L. 

Comment 81

[Guenter Lanz]

Attachment: Web-file with Screen Copy of one Thunderbird Notes list with overtypes

Attach to my previous comment - I cannot read my notes lists any more, some of the overtype texts seem to be from duplicate messages, but cannot be identified. I use WIN2000 as OpSys and did not change anything in the setup of previous Thunderbird, (only now I did try your tool Options and Compact if over... as described, but it did not change ANYTHING for this error)... Guenter Lanz

Comment 82

[Gábor Stefanik]

The new textframe landed, as well as the unit fix. Does this issue still show up?

Comment 83

[Guenter Lanz]

Just additionally: same/similar problem exist now with MOZILLA 2.0.0.7 within the 'Active Tag'-line of Firefox after opening an additional tag.
Within Thunderbird and Firefox, both I did not find new updated versions checking in the internet for it. And the error still persists... should I do anything different??? Greatful for any hint to be read also by non-system-specialists...
Thanks in advance, Guenter. Attachment folllows...

Comment 84

[Gábor Stefanik]

This is a Trunk bug, please test with a trunk build (Gecko 1.9, Firefox 3.0).

Comment 85

[klonos]

Don't see this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090420 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090420041629

Fixed?

Comment 86

[Gábor Stefanik]

Given that this is an 1px-off bug, it was most likely fixed by the unit fix.

Comment 87

[Guenter Lanz]

I am not a system specialist, I use Win2000 english, I use Mozilla and Thunderbird Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
AND I can report, the ERROR still persists in Thunderbird (the erroneous line changes when hiliting, but after changes back to error again) AND in Mozilla, can be seen in the line showing active Tags (writing/pictures overlap). HOWEVER: the error WAS disappearing when calling the older JAVA version - not any more; BUT the error IS DISAPPEARING after I START UP my HP-Scanner-Software (which obviously calls a software component making the error disappear, but I dont know which one...) That is the status today, 21.4.2009 23h...whoever can tell me,what software component is missing when calling either Thunderbird or Mozilla - tell me, plse... Guenter Lanz

Comment 88

[Wayne Mery (:wsmwk)]

Given lack of testcase from reporter, it's not clear to me this ancient bug still exists as defined by the reporter. Does attachment 125745 [details] really matches reporter's issue?  Note, reporter's email address is dead, as is Charlie's.

Perhaps this should be closed, and anyone seeing problems file a new bug.

Comment 89

[Guenter Lanz]

Since my change to new PC with Win7 this error disappeared, so no problem any more for Win7.G.L.

Comment 90

[Wayne Mery (:wsmwk)]

Anyone still seeing a problem, please file a new bug