112502 - <sup> or "vertical-align:super" changes the position of text too higher

Status: RESOLVED FIXED

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

Description

[Koike Kazuhiko]

<sup> or "vertical-align:super" changes the position of text too higher.

Testcase:
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=419


Linux build doesn't have this problem.

Comment 1

[Hixie (not reading bugmail)]

Could we have a screenshot showing the problem? I don't remember seeing this
problem when I was using Windows.

Comment 2

[Koike Kazuhiko]

Attachment: Screenshot

Comment 3

[Koike Kazuhiko]

This problem appears with Japanese font.
Text in Verdana or "Times New Roman" is displayed correctly.

Testcase:
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=592

Comment 4

[Greg K.]

Testcase WorksForMe using FizzillaCFM/2002070913.

Comment 5

[Boris Zbarsky [:bzbarsky]]

.

Comment 6

[Andrew Hagen]

This page also seems to work as a testcase. 

http://slate.msn.com/id/2080825/

Comment 7

[Boris Zbarsky [:bzbarsky]]

jshin, aren't you hacking on this sort of stuff right now?

Comment 8

[Jungshik Shin]

Yeah, but it's a Xft-specific bug. This is on Windows. Anyway, I'll take a look.
The testcase in comment #3 uses MS Gothic(ＭＳ ゴシック0, right? It could well
be due to a mistake on the font side. dbaron is not fond of overriding what's
specified in the font (not that this kind of 'overshooting' can be fixed by what
I pondered over in bug 225109, which is for too small super/sub offsets.)

OT:  When you specify a CJK font in CSS, you need to specify both 'native' names
(in CJK) AND English names because not all platform support 'native' font names.
Actually, native font names are supported only ON CJK version (or Win2k/XP with
CJK locale as the system locale) of Win9x/ME/2k/XP.  That is, instead of

font-family: ＭＳ ゴシック, sans-serif

you have to use

font-family: ＭＳ ゴシック, MS Gothic, sans-serif

Comment 9

[Jungshik Shin]

In the previous comment, the CSS font. specification issue is about the testcase
in comment #3. 

Anyway, how does MS IE handle the page? I'm being too lazy to turn on  vmware on
my Linux box to test it myself :-)

Comment 10

[Jungshik Shin]

Attachment: test case in UTF-8 that works on non-Japanese Windows

Indeed, MS IE doens't show the problem while Mozilla 1.5 still has the problem.

Comment 11

[Jungshik Shin]

In addition to bug 225109, see also bug 227452 (about different GFX ports using
different conventions for super/sub positions). I can easily take care of all of
these (so can anyone here), but we need to decide what we want to do first. 

Comment 12

[Hermann Schwab]

Attachment: screenshot win98, 200%, wfm

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050723
SeaMonkey/1.0a

Screenshot of testcase attachment 135555 [details] all selected and zoomed to 200%
Same look in all zoom states, only size changes.

Comment 13

[Hideo Saito]

Attachment: patch

I think that Japanese font (ex. MS Mincho and MS Gothic) on windows have wrong outline's text metrics. If |oMetrics.otmptSuperscriptOffset.y| is zero, the superscribed text is placed on base line of base text and if it is equel to |metrics.tmAscent|, the superscribed text is placed on top of base text. I expect that the both of |oMetrics.otmptSuperscriptOffset.y| and |oMetrics.otmptSubscriptOffset.y| are checked the range.

Comment 14

[Hideo Saito]

Attachment: patch

I think that Japanese font (ex. MS Mincho and MS Gothic) on windows have wrong outline's text metrics. If |oMetrics.otmptSuperscriptOffset.y| is zero, the superscribed text is placed on base line of base text and if it is equel to |metrics.tmAscent|, the superscribed text is placed on top of base text. I expect that the both of |oMetrics.otmptSuperscriptOffset.y| and |oMetrics.otmptSubscriptOffset.y| are checked the range.

Comment 15

[Hideo Saito]

Comment on attachment 203794 [details] [diff] [review]
patch

Sorry, I missed the operation.

Comment 16

[Hideo Saito]

Attachment: testcase for patch

Comment 17

[Hideo Saito]

Attachment: screen shot for patch

This indicates an effect for superscribed text.

Comment 18

[rbs]

Comment on attachment 203795 [details] [diff] [review]
patch

- Try using the exact xheight (it is calculated somewhere around there, instead of this 50% of ascent)

- Also try using 4/5 of xheight as the offset. (MathML uses a more complicated algorithm, but it uses that as fallback value).

Comment 19

[Hideo Saito]

Attachment: patch2

When a wrong value is in one of <sup> and <sub>, both use a calculated value, since it seems that the subscribed text is lower than best position. 

The case of MS Mincho and MS Gothic, each value is listed as follows.
ascent                 14 pixel    
descent                 2
x-height(56% of ascent) 7
x-height(glyph metrics) 7
superscript offset     14 (original)    5 (80% of x-height)
subscript offset        6 (original)    4 (60% of x-height)

Comment 20

[Hideo Saito]

Attachment: screen shot for patch2

Comment 21

[Jungshik Shin]

See also bug 225109. 

Comment 22

[rbs]

> I think that Japanese font (ex. MS Mincho and MS Gothic) on windows have wrong
> outline's text metrics.

Care to also attach a screenshot of what IE is doing with these fonts? This way, we know from now on whether they are also overriding the bad font metrics.

Comment 23

[Hideo Saito]

Attachment: screenshot for patch2 and IE

Comment 24

[Hideo Saito]

Comment on attachment 204022 [details] [diff] [review]
patch2

It seems that patch2 is suitable for alphabet since the offset is calculated using x-height, however the case of kanji, superscribed text is too lower.

Comment 25

[Hideo Saito]

Comment on attachment 203795 [details] [diff] [review]
patch

Sorry, I missed the operation again.

Comment 26

[Hideo Saito]

Attachment: screenshot for kanji

Comment 27

[rbs]

Comment on attachment 203795 [details] [diff] [review]
patch

r=rbs

Comment 28

[rbs]

Comment on attachment 203795 [details] [diff] [review]
patch

sr=rbs

Comment 29

[Hideo Saito]

Thanks rbs, could you check in to the trunk?

Comment 30

[rbs]

Checked in.