Closed Bug 174977 Opened 22 years ago Closed 10 years ago

Poor rendering of sans-serif fonts

Categories

(Core Graveyard :: GFX, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 172162

People

(Reporter: paulf, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(7 files)

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.
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?
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
Tried with Solaris x86 nightly build: problem is still there
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. 
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=patch&doc=9_Recommended.README

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
I have this problem too on both Mozilla 1.1 and Netscape 7.0 using Slackware 8.1
KDE 3.
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? 

rgds,
lasse
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!
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
1.2.10
bash-2.05$ /usr/sfw/bin/glib-config --version
1.2.10
OS: Solaris → All
Hardware: Sun → All
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.
I noticed the problem only happens when I scroll a line at a time.  If I page
down everything works.
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
http://www.derstandard.com 
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
Mozilla.
Flags: blocking1.4a?
Attached file 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. 
Flags: blocking1.4a? → blocking1.4a-
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).
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.
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.
I've now been using Mozilla 1.7 for a couple of days, and haven't yet been able
to reproduce the problem.
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
Assignee: asa → nobody
Component: General → GFX
Product: SeaMonkey → Core
QA Contact: asa → general
Product: Core → Core Graveyard
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)
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.)
Duplicate of bug 172162?
Yes, this does seem to be a duplicate of 172162
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: