192379 - Underline is too close to the font for some sites

Status: RESOLVED INCOMPLETE

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

Description

[John Paul]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030207
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030207

I tried the latest build. I found that the underline becomes too close to the
text. Until now, I can only reproduce this problem in the site
http://www.mozilla.org. And, I can't see the problem if I change the character
coding from Western to Unicode.

Reproducible: Always

Steps to Reproduce:
1.go to http://www.mozilla.org
2.look at any text with underlining
3.compare with the behaviour of moz 1.2.1 or changing character coding to unicode
Actual Results:  
The position of the underline is under the lowest point of letter 'm', upper
than it should be.

Expected Results:  
The position of the underline should be under the lowest point of letter 'g'.

Comment 1

[John Paul]

Attachment: The correct behaviour

Comment 2

[John Paul]

Attachment: The wrong behaviour

Comment 3

[R.K.Aa.]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is this only a problem with standards-mode pages?  Or also with quirks-mode ones?

Comment 5

[Rainer Bielefeld]

WFM with
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.3b) Gecko/20030204

Comment 6

[John Paul]

I still can't make conclusion when will this happen in standard or quirk mode
pages. But I have a new finding.

I'm using English ver win2k. My default language is traditional chinese and my
locale is set to chinese. Today I tried to change my locale to english. Then
everything looks fine. When I changed locale back to chinese, this problem
happens again. I suppose this problem occurs in win2k (probably win xp) when
locale set to non western language (and this may occur in non western localised
version of win 98).

Comment 7

[Boris Zbarsky [:bzbarsky]]

.

Comment 8

[Vaclav Dvorak]

Seeing this also on Linux - setting OS=All. Adding keyword regression - this
worked at least until 1.3a.

Comment 9

[Boris Zbarsky [:bzbarsky]]

On Linux, are you using an xft build or a normal build?

I suspect that this is a whole slew of separate platform bugs for the separate
GFX implementations....

Comment 10

[Vaclav Dvorak]

Standard 1.3b build. I can also confirm that this is charset-dependent:
http://www.mozilla.org/ is OK for me, and it has UTF-8 (probably in HTTP
headers). http://www.mozilla.org/start seems not to have a charset in its
headers, so I can influence the result by setting View->Character Coding.
ISO-8859-1 is OK, but ISO-8859-2 (my default) and Windows-1250 (both Central
European) are wrong. I use "adobe-times-iso8859-1" for Western coding, and
"urw-nimbus roman no9 l ee-iso8859-2" for Central European. The font is OK - it
works fine in other apps, and it worked fine in Mozilla 1.3a and earlier versions.

Comment 11

[Dvir]

I'm seeing this problem with the latest nightly build (20030427) on
www.mozilla.org . There wasn't any problem with 1.3.

Comment 12

[Yuying Long]

Nominate as nsbeta1 for now.  Looks like doesn't has the same problem on latest
Mac OS X trunk build though.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could this be a problem with the font that's being used?  What font is shown in
the screenshots?

Comment 14

[Samir Gehani]

adt: nsbeta1-

Comment 15

[KANEUCHI Tetsuya]

I saw this problem on 2003052307/Mac OS X bulid. I'm sure it depends on the font
setting.
Sans-serif font setting:
   Helvetica:      No problem.
   Lucida Grande:  Too close (this bug appeared)

I see this problem in standards-mode page only. No problem with quirks-mode.

Comment 16

[KANEUCHI Tetsuya]

Related to bug 1777?

I've build with Mac OS X,
make -f clieknt.mk MOZ_CO_DATE=2002-12-11  --> Good
make -f clieknt.mk MOZ_CO_DATE=2002-12-13  --> NG
(2002-12-12 --> build failed)

Comment 17

[Won kyu Park]

This is a related site to show how to properly render the underline.
http://firefly.idv.tw/setfont-xft/ChangeLog.html

without a underline patch:
http://firefly.idv.tw/setfont-xft/screenshots/mozilla-underline-old.png

with the underline patch made by firefly.
http://firefly.idv.tw/setfont-xft/screenshots/mozilla-underline-new.png

and the underline patch made by firefly
http://firefly.idv.tw/setfont-xft/patches/mozilla/mozilla-1.4-xft_cjkfamilyname-20030703.patch

please see also the screenshot:
 * MS windows: http://chem.skku.ac.kr/~wkpark/pds/UnderlinePosition/ms_georgia.png
 * under the Linux(RedHat9)
http://chem.skku.ac.kr/~wkpark/pds/UnderlinePosition/linux-georgia.png
                                                                   
the underline also eat '_'(underbar) with some TTF fonts :(

Comment 18

[Jungshik Shin]

The patch is summed up as following: 

+    // 列間距一律三個單位 : 
+    mLeading = NSToIntRound(f * 3);

  

+    // 底線在字的下面, 而不是疊在字的最後一條線
+    mUnderlineOffset = -NSToIntRound(f) +
+        -NSToIntRound(PR_MAX(1, floor(0.1 * xftFont->height + 0.5)) * f);

+    // 底線厚度一律一個單位, 太粗不好看 :-p
+    mUnderlineSize = NSToIntRound(f);
 
I don't feel very comfortable with the first and the third. Always setting
mLeading to 3 units doesn't seem right. Neither does always setting the width of
the underline to 1 unit, but ....

re comment #6 : CJK langGroup is special-cased in nsFontMetricsWin.cpp, which
appears to explain why you observed only in SC locale. 

Comment 19

[Jungshik Shin]

See the discussion in bug 156943 (espeically bug 156943 comment #24). Whether
the underline should be below or above w.r.t the bottom stem of 'g' or 'p' is
debatable. Howeer, the symptom reported in comment #6 seems to be the opposite
of what I'd expect from the fact that patches for bug 156943 were made to be
effective only for CJK fonts (when mLangGroup=CJK). 

Anyway, for Xft build, we may have to try something similar to what Shanjian did
for GFX:Win. 

Comment 20

[Jungshik Shin]

I'm sitting in front of Windows XP (ko) and what I'm observing (with 20030528 :
1.4alpha : sorry that's what I have on my CD-ROM at the moment) is consistent
with what's done in bug 156943. That is, when I set View - Character Coding to
one of CJK (with Edit | Pref | Appearance | Font | Allow doc to use other fonts
set to FALSE), the underline is well off the 'lowest' descent of any glyph.
However, with character coding set to non-CJK, it very much depends on fonts.
Fonts like Verdana  look nice. However, with Arial,  Tahoma, Lusida Sans
Unicode, the underline crosses 'g' and 'p'. If that's the intent of font
designers, that's fine. In summary, WFM on Windows XP. [1] The second last
screenshot in comment #17 also confirms that. Compare that with the last
screenshot in comment #17 that is taken on Linux with Mozilla-Xft. GFX:Win (ko)
works fine while Mozilla-Xft does not. 

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsXft.cpp#981

981     // mUnderlineOffset (offset for underlines)
982     val = face->underline_position >> 16;
983     if (val) {
984         mUnderlineOffset = NSToIntRound(val * f);
985     }
986     else {
987         mUnderlineOffset =
988             -NSToIntRound(PR_MAX(1, floor(0.1 * xftFont->height + 0.5)) * f);
989     }

In line 982, face->underline_position is short so that val is always 0, isn't it? 
(there are a couple of more lines like that)
It seems like line 982 has to be 

  val = CONVERT_FROM_DESIGN_UNIT(
         face->underline_position, face->size->metrics->x_scale)
 
  with the following macros (taken from nsFontFreeType.cpp) FT_MulFix (defined
in freetype) is (v * s >> 16) 

 #define FT_CEIL(x)  (((x) + 63) & -64)
 #define FT_TRUNC(x) ((x) >> 6)
 #define CONVERT_FROM_DESIGN_UNIT(v, s) FT_TRUNC(FT_CEIL(FT_MulFix((v), (s))))

However, this doesn't change things much. Because in effect, the fallback in
else-clause gives us more or less the same value. I don't know why font
designers (of CJK fonts) assign so small values to 'underlinePosition'. Anywy,
that sure is problematic in rendering with CJK fonts and  we need to work around
it as was done in bug 156943.

In case of GFX:Mac, both underlineOffset and underlineSize are set to one pixel
(bug 2439) ! That part of the code hasn't been changed for a long time. So, I
have no clue what to make of comment #15. 

[1] John's two screenshots in comment #1 and comment #2 appear to use the same
font. Again, I have no idea why he got exactly the opposite result. 

Comment 21

[Jungshik Shin]

Re: comment #4
Boris, it only happens in standard mode. After writing my last comment, I
realized that bugzilla pages (like this) doesn't have the problem while with
exactly the same font www.mozilla.org page has the problem. I just found that
the former is rendered in quirk mode while the latter is in standard mode. John,
you can figure it out in View | Page Info (or pressing Ctrl-I)

It looks like it's caused by the checkin for bug 1777 except that the
'regression window' narrowed down in comment #15 is slightly off (perhaps CVS
time is in UTC while 'lxr' time is in US PST = UTC - 0800 :
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&file=nsHTMLContainerFrame.cpp&rev2=3.174&rev1=3.173)
The patch for bug 1777 touched several files in layout/html/base/src (that all
invoke nsIFontMetrics#getUnderline)

CJK-specific change (as was done in GFX:Win in bug 156943) for GFX:Gtk(Xlib,
Xft), GFX:Mac and other GFX ports have to be a sepaate bug.

I'm changing the component to layout:font and text

Comment 22

[Jungshik Shin]

I filed bug 218032 on adjusting the underline position for  CJK-font specific
change. I feel stupid not having noticed that KANEUCHI-san had alrady found what
I wrote in the last comment.

Comment 23

[Uri Bernstein]

Reading the comments, this *might* be the same as bug 210330 (for which a patch
was just checked in).
(If it is, I should have probably marked that bug as a duplicate of this one -
but I guess it's too late for that now.)

I'm a bit confused as to how to reproduce this (the comments indicate there
might be several issues here). If someone can still reproduce this bug, it would
be nice to see if the patch to 210330 fixes it.

Comment 24

[Mark Lam]

This issue still has not resolved by now.
CJK text underline is positioned too near the text in Deer Park 1.6a
I hope developer can take care of the issue.

Comment 25

[Mark Lam]

Firefox in Windowns is OK.
But in Linux this issue is boring thing for CJK users.

Comment 26

[MarjaE]

As of 52 esr, depending on user font settings, most underlines may appear as strikethroughs.

Comment 27

[MarjaE]

For the record, I usually use OpenDyslexic, with 16 pt or 20 pt minimum font size. Other fonts and smaller sizes mean more eye-strain.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:jfkthame, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 29

[Jonathan Kew [:jfkthame]]

I don't think the original issue here is relevant any longer; much has changed in the font/text rendering code since this was filed.

Firefox relies on metrics from the font to determine the underline position, and AFAIK this works as intended. Occasionally there may be fonts with poorly-chosen metrics, in which case there are CSS controls that can be used to adjust the result.

If there are current examples of poor rendering, please file new issues for investigation.