Poor rendering of sans-serif fonts



Core Graveyard
15 years ago
4 years ago


(Reporter: Paul Floyd, Unassigned)


Bug Flags:
blocking1.4a -

Firefox Tracking Flags

(Not tracked)




(7 attachments)



15 years ago
This happens both on Solaris 8 x86 and Solaris 7 SPARC, both with Mozilla 1.1.

On pages that have a lot of text, when I scroll down to read, lines get rendered
with missing scanlines. The example page above uses
<font face="Arial, Verdana, sans-serif">

It makes no difference whether I add the a TrueType directory to the font path.

Comment 1

15 years ago
Created attachment 103174 [details]
Image showing poorly rendered font

Comment 2

15 years ago
Added attachment.
In the line " Jamaican Prime Minister " you can see that the scanline passing
through the centre of the letters is missing, so that the horizontal parts of
"a"s and "e"s is not visible.
In the line "The UN rapporteur for Burma", it is the scanline at the very bottom
of the text that is missing.
Lastly, in the line " European reinforces controls", it is towards the top of
the letters that there is a scanline missing,].
WFM, Mozilla 1.1b, Solaris 8 on Sparc. Reporter, does this happen with the
latest nightly?

Comment 4

15 years ago
The latest nightly bombs just afer the main window is displayed, printing
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  66 (X_PolySegment)
  Serial number of failed request:  1160
  Current serial number in output stream:  1175
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  66 (X_PolySegment)
  Serial number of failed request:  1162
  Current serial number in output stream:  1176

Comment 5

15 years ago
Tried with Solaris x86 nightly build: problem is still there

Comment 6

15 years ago
This bug has been around for a while, but I couldn't find another entry. It
doesn't only happen on sans-serif fonts: See e.g. 

The problem occurs on the upper and lower edge of the window when scrolling text
into the window. I've seen similar things happen with images too, by the way.
According to the n.p.mozilla.unix newsgroup, this might also occur on RedHat.
Ever confirmed: true

Comment 7

15 years ago
Created attachment 104833 [details]
Error rendering fonts on slashdot.org

I've had the same problem on both Gentoo and RedHat linux.

The Gentoo Moz is:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021020

I'm seeing it on many pages I view - including the bugzilla pages of
mozilla.org, slashdot.org and many many more.

Created attachment viewing slashdot.org.

It seems that if I mark the badly rendered text with the mouse it will correct
and rerender properly.

Comment 8

15 years ago
I have this problem too on both Mozilla 1.1 and Netscape 7.0 using Slackware 8.1
KDE 3.

Comment 9

15 years ago
Same problem with RedHat Linux 8.0,  mozilla 1.1 - 1.2b & Galeon 1.2.6. 

It seems that this bug is incorrectly set to be Sun Solaris specific. Could
someone please change that? 


Comment 10

15 years ago
Created attachment 107487 [details]
Bad font rendering viewing a swedish Gnu-news site.

Comment 11

15 years ago
Been seeing this with rh7.2 (up-2-date'd) in Galeon and Mozilla 1.0.1 for quite
a while. Thought it was probably video card. Replaced with new different type of
card and still see the problem. The attachments provided above look just like
the kind of text distortions I see. Definitely not just a solaris problem!

Comment 12

15 years ago
This problem is still there using the current 1.3b from today (2003-02-03).
Changing the platform and os to 'all' by popular request.
To everyone on the CC-list: which GTK and glib library is Mozilla using?
bash-2.05$ /usr/sfw/bin/gtk-config --version
bash-2.05$ /usr/sfw/bin/glib-config --version
OS: Solaris → All
Hardware: Sun → All

Comment 13

15 years ago
This bug also extends to images, not just text.
Example: http://www.dpreview.com/reviews/nikond100/page17.asp
Scroll down this page slowly, untill you see the picture below the word 'Night
Images'. Now move your pointer over each of the images, and you will see them
each become one pixel taller (extending downwards) all of a sudden.

Comment 14

15 years ago
I noticed the problem only happens when I scroll a line at a time.  If I page
down everything works.

Comment 15

15 years ago
I agree, single line scrolling triggers it more. Its seems that when a text line
is bisected by the upper or lower window border and then scrolled into view it
often (but not alway) gets distorted. When you page up and and then down, the
distored line is repaired. Also, I think I see it less often when I set "allow
document to use other fonts" in the fonts dialog.
This happens frequently e.g. on one of Austria's largest online newspaper site
For small font sizes, the text is sometimes close to unreadable. This is highly
visible and leaves a rather bad impression. 
One of the things that people here complain about most often to me when using
Flags: blocking1.4a?
Created attachment 117413 [details]
Example as seen with Mozilla 1.3 or 2003031605 (linux).
Created attachment 117415 [details]
Simple testcase

With this testcase, I only ever see the problem within the first div (i.e.
before the horizontal ruler). The only difference is that the first block uses
line-height: 17px and the second one line-height: 16px. 

Further testing seems to indicate that the problem only occurs with odd px
values for the line-height attribute, never even values.
Making this block bug 134942, other bugs dependent on bug 134942 might be
related or even DUPes?
Blocks: 134942
This seems to be related to the display resolution settings (in
preferences->appearance->fonts): this was set to "system settings", but when I
change to 96dpi, I cannot reconstruct the problem in the testcase anymore. When
I set it to 72dpi, I see the problem, but less pronounced. Switching dpis
relyably makes the problem appear and go away. 
When I render the testcase with three different dpi-settings in three tabs and
then switch between them, the font sizes appear *exactly* the same, but with the
settings that cause problems, the vertical whitespace on top of the page seems
to be just one pixel larger. 


15 years ago
Flags: blocking1.4a? → blocking1.4a-

Comment 22

15 years ago
Created attachment 126992 [details]
added a test-image to previous "Simple testcase"

the image that is included repeatedly in the html-file consists out of black
and white horizontal lines, so the image appears normally plain grey. you can
see that the images are also affected from the bug: single horizontal white or
black lines (two pixels high) appearing on the screen because single rows from
the source image are dropped during srcolling.

if you select the affected images or text-lines all is repainted correctly.

the corruption is generated at the top and bottom of the visible part of the
page. a single pixel row of the whole page is dropped. it is irrelevant which
scrollmethod you chose, the bug is always there. but smaller scrollsteps leads
logically to more rowdropping, so you can recognize it easier.

i recognised this bug through several mozilla-versions (0.9 - 1.4) on different
flavors of linux (redhat, gentoo).

Comment 23

14 years ago
It's been a while since the last entry to this bug. Anyone else than me still
experiencing the problem?

I noticed a strange thing. Trying out Gnome 2.6 just now it seems that this bug
is not in effect there. Yet it's still in effect under WindowMaker. Perhaps this
is an issue in the Mozilla/Windowmanager integration? Could somebody please 
verify/deny this?

I'm currently running Firefox 0.8 under WindowMaker 0.80.1. The Gnome desktop is
2.6 using metacity as window manager.

Comment 24

14 years ago
The problem is certainly still there with Gnome 2.0 and Mozilla 1.6 Solaris x86.
I'll check with Mozilla 1.7 SPARC at work tomorrow.

Comment 25

14 years ago
I've now been using Mozilla 1.7 for a couple of days, and haven't yet been able
to reproduce the problem.

Comment 26

13 years ago
I am seing this too with FireFox 1.0 (Linux/Suse9.1/KDE3.3.1).

In an attempt to put things together, I am listing here bug reports that seem
related to me. Sorry for not doing more analysis (and reading all the comments
of all bugs listed here) or for the bugspam but I really think this linking
might be useful. Please note that this bug is listed too (as I put the same in
different bugs).

bug 172162 Linux
bug 174977 All (was Solaris)
bug 199840 Linux
bug 211704 Linux
bug 215759 Linux
bug 217336 Linux
bug 217825 All (was Linux)
bug 228808 MacOS X
bug 248799 Linux

I built this list by searching for scroll and font in the comments from newest
to oldest going up to the first one of this list (feel free to search further)
and I might have missed some.

I put the OS as it seems there is a link between them: is it due to the usage of
a common deployed library, a bug in an OS' library, ...?
Product: Browser → Seamonkey


9 years ago
Assignee: asa → nobody
Component: General → GFX
Product: SeaMonkey → Core
QA Contact: asa → general


9 years ago
Product: Core → Core Graveyard

Comment 27

9 years ago
I think this is fixed 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.

So, fixed then?

(Screenie of what I see follows)

Comment 28

9 years ago
Created attachment 373800 [details]
Screenshot of testcase in latest 3.6a1pre nightlies (issue fixed?)

Comment 29

9 years ago
I think that this can be closed - I haven't seen this problem for some time (though this could be due to OS upgrades etc.)

Comment 30

4 years ago
Duplicate of bug 172162?

Comment 31

4 years ago
Yes, this does seem to be a duplicate of 172162


4 years ago
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 172162
You need to log in before you can comment on or make changes to this bug.