160697 - Subscripts not lower enough

Status: RESOLVED WONTFIX

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

Description

[石庭豐 (Seak, Teng-Fong)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020802
BuildID:    2002080204

Subscripts using <sub> tags, in my opinion, aren't lower enough.  Esp, if the
base font uses small font-points.  Compare
x<sub>2</sub>
in Mozilla with N4 or IE and you'll see the difference.

Reproducible: Always

Comment 1

[Hideo Saito]

This problem may be windows only. This bug is repaired at once.
Please refer to Bug 9640 and
http://bugzilla.mozilla.org/show_bug.cgi?id=156943#c63.

It seems that it returned from the new version than mozilla-1.0.
In the English characters, a small character moves too small movement of the
upper or lower sides, in the CJK characters, a small character moves too much up
or down.

Comment 2

[Hideo Saito]

Attachment: Screenshot of western character coding

Comment 3

[Hideo Saito]

Attachment: Screenshot of Japanese character coding

Comment 4

[Hideo Saito]

character coding Western   <sub> not lower enough
                           <sup> good
                 Jpapanese <sub> good
                           <sup> too higher

See also Bug 112502.

Comment 5

[Hideo Saito]

Please also refer to 
http://bugzilla.mozilla.org/show_bug.cgi?id=156943#c64.

Comment 6

[Hideo Saito]

Attachment: testcase

Comment 7

[Hideo Saito]

Attachment: patch

It seems that subscripts are not lower enough in English but they are too lower in Japanese. I think that it is better for offset of the scripts using x-height than using font metrics. I chose 40% of xHeight.

Comment 8

[Hideo Saito]

Attachment: screen shot for original

Comment 9

[Hideo Saito]

Attachment: screen shot for 40% of x-height

Comment 10

[Hideo Saito]

Attachment: screen shot for 50% of x-height

Comment 11

[rbs]

You were driving bug 112502 recently and made the case for the existing code. Why the U-turn?

Also, when a value is rightly set by font-designers, that's what they want it to be. Overriding means that we are telling them that know their own fonts better than them (and discourage them from honoring the contract in future fonts).

If you must adjust in the case of unset metrics, why not do:

    if (oMetrics.otmptSubscriptOffset.y == 0 || oMetrics.otmptSubscriptOffset.y >= metrics.tmAscent)
-     mSubscriptOffset =  mXHeight;     // XXX temporary code!
+     mSubscriptOffset =  mXHeight * 0.4f; // 40% of xHeight
    else
      mSubscriptOffset = NSToCoordRound(oMetrics.otmptSubscriptOffset.y * dev2app);

Comment 12

[Hideo Saito]

For example, if font-size is 19 pixels, otmpSubscriptSize is 10 pixels and otmpSubscriptOffset is 2 pixels, however, actually used font-size for subscripts is 15 pixels. I think that otmpSubscriptOffset should not be used directly since actually used font-size differs from otmpSubscriptSize.

case of Times New Roman:
metrics
 tmHeight            19     15       27
 tmAscent            15     12       21
 tmDescent            4      3        6
oMetrics
 otmpSubscriptSize   10              16     
 otmpSubscriptOffset  2               3

Comment 13

[Hideo Saito]

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

I think that the offset should be calculated from otmptSubscriptSize and otmptSubscriptOffset, based on the font-size of the subscripts.

Comment 14

[rbs]

[Typo... Overriding means that we are telling them that [WE] know their own fonts]

When I saw your comment 12, I started to wonder if layout was picking the right font-metrics (since <sup>/<sub> entails font-size: smaller in the sub/superscript, and it would be wrong to use the offsets from the smaller font). But I have now checked nsLineLayout::VerticalAlignFrames() and it is rightly using the parent's font-metrics to determine the offsets of the sub/superscript.

I do not actually dislike attachment 208509 [details] (original) since it is a recent iteration from what you did in bug 112502, and would go with what I suggested in comment 11 if you have to.

Comment 15

[Hideo Saito]

> and would go with what I suggested in comment 11 if you have to.

I do not have a plan to adjust the offset for the special case of Japanese subscript since the offset is in range (metrics.tmAscen > oMetrics.otmptSubscriptOffset.y > 0) as to our usual font.

> I do not actually dislike attachment 208509 [details] [edit] (original)

Is this bug WONTFIX?

Comment 16

[rbs]

I think so. The other Gfx ports are not tampering with the metrics either.

[Perhaps, the real issue is to use something other than "font-size: smaller" for <sub>/<sup>. This way, layout could use the right font-size (otmptSubscriptSize/otmptSuperscriptSize) specifically recommended by the font-designer for the sub/superscript. But that's more involved because we will then need to support things like "font-size: -moz-subscript" and "font-size: -moz-superscript", and add new APIs to fetch otmptSubscriptSize/otmptSuperscriptSize... Better to see if cairo will fare better.]