<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.

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

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

Testcase WorksForMe using FizzillaCFM/2002070913.

.

This page also seems to work as a testcase. http://slate.msn.com/id/2080825/

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

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

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 :-)

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

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.

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.

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.

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 on attachment 203794 [details] [diff] [review] patch Sorry, I missed the operation.

This indicates an effect for superscribed text.

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).

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)

See also bug 225109.

> 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 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 on attachment 203795 [details] [diff] [review] patch Sorry, I missed the operation again.

Comment on attachment 203795 [details] [diff] [review] patch r=rbs

Comment on attachment 203795 [details] [diff] [review] patch sr=rbs

Thanks rbs, could you check in to the trunk?

Checked in.