225109 - SUP and SUB positioning : follow the 'rule of thumb' extracted from TeX algorithm

Status: NEW

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

Description

[Jungshik Shin]

a spin-off of bug 222920

TeX uses a sophisticated algorithm to determine the position of superscript and
subscript. Mozilla can't do that, but it may be a good idea to implement the
following simple rules:

 1. The bottom of superscripts should be at least  the 4/5th of xheight. 
 2. The top of subscripts should be at most the 4/5th of xheight.
 3. as a corollary of 1 and 2, when attached to the same 'base' character,
subscript and superscript
     wouldn't touch each other.

Currently, when the super/subscript position is not specified in a font, Mozilla
uses 'xheight' for both superscript and subscript offsets. So in that case, the
above conditions are more or less satisfied.

The question is whether to enforce the above rule when the super/subscript
offsets specified in a font  are too small to meet the condition above.  That
is, should Mozilla override the font designer's choice? In one case(Bitstream
Vera Serif), I found that the sign of the subscript offset is wrong and Mozilla
ends up using just one pixel as the subscript offset. (if the sign was right,
Mozilla would use about half of xheight as the subscript offset).  In some other
fonts, about half of xheight is specified for super/subscript offsets. With
those values, the above condition cannot be met at all. 

A related question is the size of sub/superscripts. nsIFontMetrics doesn't have
properties for them and it seems like it's hard-coded somewhere in the layout
code. To enforce the rule #2, we have to know the subscript size. Some truetype
fonts have them specified in the OS2 table. If not available from fonts(or it's
too large), I guess we can use the 70% rule of TeX (currently it appears that
it's more than 70%).

Comment 1

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

I'm against modifying metrics that the font provides.

Comment 2

[Jungshik Shin]

What about so obviously wrong metrics?  Bitstream Vera has the incorrect sign 
for subscript offset. Are you even against protecting us against that kind of 
mistake? 

BTW, what size do we use for super/subscript? Some truetype fonts have 
super/subscript size specified in OS2 table, but apparently we don't use them. 

Comment 3

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

sub and sup have 'font-size: smaller' in html.css.

Fixing the sign seems ok, I guess...

Comment 4

[Jungshik Shin]

Attachment: a patch to fix the sign

I may as well file a separate bug for this, but it was mentioned here and got
'nodded' by dbaron... This is to work around the incorrect sign of the
subscript offset value stored in the OS2 table of some truetype fonts (most
notably, Bitstream Vera fonts released to the opensource community).

Comment 5

[Jungshik Shin]

Comment on attachment 136732 [details] [diff] [review]
a patch to fix the sign 

asking for r/sr. 
This is a simple one-liner.

BTW, I took a look at other ports of Gfx. Only Gfx:Win and Gfx:Gtk-Xft read the
super/subscript offsets from fonts at the moment. In case of Gfx:Win, it's
using Win32 API instead of reading values from the OS/2 table directly so that
I guess we may as well 'trust' Win32 API to do the right thing. So, the only
place we need to do this sign fix-up is in Gfx:Gtk-Xft.

Comment 6

[rbs]

Comment on attachment 136732 [details] [diff] [review]
a patch to fix the sign 

>I found that the sign of the subscript offset is wrong

I suspect it may just be a difference in the coordinate system (rather than
being "wrong" per se. Remember the salsa dance with GetBoundingMetrics?).

Comment 7

[Jungshik Shin]

Thanks for r. 
As for the sign, there are different conventions in _different_ font formats and
different APIs. However, what we're dealing with here is a single format
(truetype font, OS2 table), the specification of which is very clear about the
sign convention of the subscript offset. See
http://www.microsoft.com/typography/otspec/os2.htm

quote> Values are expressed as a positive offset below the character baseline

Comment 8

[Jungshik Shin]

Comment on attachment 136732 [details] [diff] [review]
a patch to fix the sign 

asking for a1.6

this is a trivial fix to work around the incorrect sign used in some truetype
fonts (notably Bitstream vera fonts widely used on Linux).

the fix is for the Xft-build so that it's not a part of the default build.
Anyway, the risk is very low.

Comment 9

[chris hofmann]

Comment on attachment 136732 [details] [diff] [review]
a patch to fix the sign 

a=chofmann for 1.6.  this needs to go on the branch at this point to make it
into 1.6

Comment 10

[Jungshik Shin]

fix checked into the trunk and the 1.6branch

Comment 11

[Andrew Hagen]

Can this be resolved as fixed?

Comment 12

[Mike Brown]

I wouldn't say it's fixed if it's only fixed for one platform. Why only fix it for X11? I am using the Bitstream Vera fonts on Windows and am seeing superscript where there should be subscript, in Firefox 1.0.7.

Comment 13

[Jungshik Shin]

(In reply to comment #12)
> I wouldn't say it's fixed if it's only fixed for one platform. Why only fix it
> for X11? I am using the Bitstream Vera fonts on Windows and am seeing
> superscript where there should be subscript, in Firefox 1.0.7.

Well, basically this is not Mozilla's problem but that of the font. We added a work-around for it for Xft because Bitstream Vera is  widely used on Linux, but this should be fixed by the foundry.  

Comment 14

[Gordon P. Hemsley [:GPHemsley]]

So, this bug was fixed for a single common font on Linux back in 2003, but not for any other platform since then.

And, if I'm understanding this right, this is a bug I'm stilling seeing in Firefox 3.6.x. Namely, the superscripts and subscripts take up way too much space above and below the regular line. However, Safari doesn't appear to have this problem.

Very brief troubleshooting makes me wonder if the use of the 'line-height' property on sub and sup has anything to do with it. Firebug tells me that it's used in Firefox, set to 'normal'. The "typical default display properties" section in the HTML5 Markup document (<http://dev.w3.org/html5/markup/sub.html#sub-display>), which I'm told is generated from WebKit, omits that styling.

Either way, I think I prefer the way Safari handles sub/sup, and it would be nice if Firefox could be changed to match.

Comment 15

[Boris Zbarsky [:bzbarsky]]

"normal" is the default value of line-height.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Note also that comment 14 has nothing to do with this bug as originally filed.  This bug was about making sure the subscript and superscript don't end up overlapping each other.  Comment 14 seems to be about not putting them too far apart, which is exactly the opposite problem.

Comment 17

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #16)
> Note also that comment 14 has nothing to do with this bug as originally filed. 
> This bug was about making sure the subscript and superscript don't end up
> overlapping each other.  Comment 14 seems to be about not putting them too far
> apart, which is exactly the opposite problem.
Apologies for that. I couldn't figure out whether the bug I was talking about already existed, or whether I should file a new one. I came across three that seemed similar, and this was the first. (The other two were bug 227452 and bug 570424.)

Comment 18

[Alan Thomas]

Reset assignee, this has been assigned for 10 years with no real progress.

Comment 19

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)