226590 - Link underline is a pixel too far from baseline of text

Status: RESOLVED DUPLICATE of bug 219225

(Core :: Layout: Text and Fonts, defect)

Description

[Sandhya]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Underlining of links is typographically incorrect.

Open any site, and look at the position of the underline of links. Compare it to
Netscape 4.x, IE, Safari etc. Mozilla's underline is too far from the baseline.
Mozilla's underline is jarring, and is typographically incorrect.

To see the typographically correct underline, use Microsoft Word, and underline
some text. Or, if you have the professional version of Adobe Acrobat, use it to
convert an HTML page to PDF and open that PDF.

Adobe, Microsoft and Apple are all in agreement about the position and size of
the underline.

Mozilla's renderer should be consistent with Adobe, Apple and Microsoft.


Reproducible: Always

Steps to Reproduce:
1. Open any website, such as http://www.cnn.com
2. Observe the position of underline (of links) relative to baseline of text
3. Compare to Netscape, IE, Safari, Microsoft Word, Adobe Acrobat

Actual Results:  
Underline position is too far below the baseline of text.

Expected Results:  
Underline should be closer to the baseline of text, more like Netscape 4.x

Comment 1

[Boris Zbarsky [:bzbarsky]]

This worksforme with a current Linux trunk build (x11core fonts).  Is this
Windows-only?  Or just a problem with a particular font?

Comment 2

[Sandhya]

I have not tried this on Linux. This may be Windows-only. The issue is not
limited to any particular font.

Comment 3

[Bill Mason]

Well I'm looking at the page in Times New Roman with Netscape 4.8 and build
20031121 PC/WinXP, and there's no difference in the rendering.

Comment 4

[Sandhya]

I have provided a screenshot of Netscape 4.7 vs Mozilla 1.5 here:
http://www.mayura.com/bug226590.png
I used the CNN website for this comparison, but the problem is not limited to
that website.

Comment 5

[Sandhya]

Attachment: Comparison of Netscape 4.x with Mozilla 1.5

Comment 6

[Alex Eng]

Reproduced on build 2004030108
Mozilla/5.0 (Windows; U; Win98; en-US; rv:) Gecko/20040301

As stated in comment #3, this issue doesn't seem obvious with the Times New
Roman font, 12pt.  But the difference is apparent in bold, larger sizes; e.g.
<h1>, <h2>.  Perhaps this depends on the font used, and the font size.

Confirming and moving to Layout.

Comment 7

[jr-mozillabugs]

The incorrect underline placement makes "q" and "g" indistinguishable with
certain fonts.

Try this on Windows:

<span style="font: 10pt verdana; text-decoration: underline">g<br />q</span>

Comment 8

[jr-mozillabugs]

Attachment: Comparing underline placement between Mozilla FF 0.9, IE 6, and WordPad

Comment 9

[Uri Bernstein]

Marking as duplicate of bug 219225. CC'ing bzbarsky to verify this is indeed a
duplicate.

*** This bug has been marked as a duplicate of 219225 ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

The only way to verify is to test a build with that fix and verify that the
problem here is gone....  Can't really do that, since the problem seems to be
rather font-related and my fonts don't show it...

Comment 11

[Uri Bernstein]

(In reply to comment #10)
> The only way to verify is to test a build with that fix and verify that the
> problem here is gone....  Can't really do that, since the problem seems to be
> rather font-related and my fonts don't show it...

Bug 219255 doesn't have a fix, yet (you were probably thinking of bug 210330).
I was just going over underline-related bugs (looking for duplicates of 210330),
and happened to find this one and 219255, which seem very much like duplicates
according to their descriptions and comments (note also they are both
Windows-only). 
If someone feels/knows this is wrong, please re-open.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, sorry.  Yes, I was thinking of bug 210330.  My comment stands, though --
duplicates should be verified when the bug they were duplicated to is fixed,
since they may need to be reopened at that point.