Rename OverShift and UnderShift for munder/mover/munderover layout

[fred-wang]

Shifts are from the baseline in OpenType MATH (see w3c/mathml#123)

We should instead use "OverRise" and "UnderDrop" as in the corresponding parameters.

[fred-wang]

Actually, checking https://docs.microsoft.com/en-us/typography/opentype/spec/math more carefully it seems we have 2 kinds of parameters. Currently, the MathML Core spec always interpret things relative to the ink top of the base, but I think as in w3c/mathml#123 the latter should be interpreted relative to the baseline:

upperLimitBaselineRiseMin/lowerLimitBaselineDropMin (relative to the ink top of the base)

and

stretchStackTopShiftUp/stretchStackBottomShiftDown (relative to the baseline)

@SergeyMalkin Can you please confirm?

[fred-wang]

This may contribute to bugs like https://bugs.chromium.org/p/chromium/issues/detail?id=1357162

But we would need feedback from Microsoft here...

[ronkok]

I write in support of @fred-wang and his comments just above. And below, I present some research on extensible arrows. The following table uses five different methods to set the vertical position of the upper element.

As you can see in line 1, the current Chromium <mover> places top elements too high for certain fonts. And line 2 matches the placement, which makes it pretty clear that the problem occurs because StretchStackTopShiftUp has been treated as a gap distance, not a shift from the baseline.

Properly done, the algorithm should render the maximum of line 3 and line 4. I believe that’s what we would get with Fred’s proposed change in terminology. Thus, the MathML-Core specification should be amended as Fred suggests.

For background, I have tabulated values from several math fonts. If you would like to verify my work, you can plug one of these values into the raisebox distance of this template.

Item	Latin Modern	Cambria Math	STIX TWO	Libertinus	Asana
em height	1000	2048	1000	1000	1000
Ink height of ⟶, U+27F6	510	998	460	448	491
StackGapMin	120	400	150	200	348
StretchStackGapAboveMin	200	133	68	65	80
StackTopShiftUp	444	960	470	470	50
StretchStackTopShiftUp	111	1600	800	800	50

[ronkok]

To be more specific, I propose the following edit to MathML-Core specification section 3.4.2.4 Base with overscript. This edit, written in bold, occurs after the line which reads “Parameters OverShift and OverExtraDescender are determined by considering three cases in the following order:“

      ⋮

2. The mover base is an embellished operator with the stretchy property and stretch axis inline. OverShift, from the baseline, is the maximum of:

• StretchStackTopShiftUp (from the baseline)

• StretchStackGapBelowAboveMin + the descent of the mover overscript + the ink height of the stretchy element.

[fred-wang]

Thanks for your feedback.

Yes, your proposal seems correct for OverShift and the stretchstack case.

However, there are more cases (munder/mover/munderover, under script, cases 1. 2. & 3. etc) so the spec changes should properly take all of them into account (description, SVG figure and parameter names). In particular, I don't think just adding "from the baseline" will work given how OverShift is represented and used elsewhere.

Anyway, before doing any editorial change we still need to confirm the interpretation of stretchStackTopShiftUp/stretchStackBottomShiftDown. If we can't get feedback from Microsoft maybe the "naming convention" described in https://learn.microsoft.com/en-us/typography/opentype/spec/math is enough to claim they are relative to the baseline, similar to what we currently have for subsup scripts or fractions.

[davidcarlisle]

@MurrayIII could you comment on the above to clarify the Opentype parameter specification?