[MATH] The algorithm for applying MathKernInfo is incorrect

[khaledhosny]

The spec has the following text:

The kerning algorithm for subscripts and superscripts is as follows:

• Calculate the vertical positions of subscripts and superscripts using the MathConstants table.
• Set the default horizontal position for a subscript immediately after the base glyph.
• Set the default horizontal position for a superscript after the base, applying a shift for italics correction if indicated for the base glyph in the MathItalicsCorrectionInfo table.
• Calculate a superscript kerning value as follows:
  • Evaluate two correction heights (illustrated in the figure below):
    • At the bottom of the superscript-glyph bounding box. (The corresponding height for the base glyph is the distance from the base-glyph baseline to the bottom of the superscript bounding box.)
    • At the top of the base-glyph bounding box. (The corresponding height for the superscript glyph is the distance from the superscript baseline to the top of the base-glyph bounding box.)
  • For each correction height, add the top-right kerning value for the base glyph to the bottom-left kerning value for the superscript glyph.
  • Take the minimum of these two sums: kern the base and superscript by that amount.
• Calculate a subscript kerning value as follows:
  • Evaluate two correction heights:
    • At the top of the subscript-glyph bounding box. (The corresponding height for the base glyph is the distance from the base-glyph baseline to the top of the subscript bounding box.)
    • At the bottom of the base-glyph bounding box. (The corresponding height for the subscript glyph is the distance from the subscript baseline to the bottom of the base-glyph bounding box.)
  • For each correction height, add the bottom-right kerning value for the base glyph to the top-left kerning value for the subscript glyph.
  • Take the minimum of these two sums: kern the base and subscript by that amount.

Since kerning is usually negative, following the letter of the spec will result in the greater amount of kerning being applied e.g. if -100 and -200 are calculated, the applied kerning would be -200. However, Word actually takes the least amount kerning, so -100 is what get applied. This makes sense since applying the greater kerning can result in parts of the glyphs clashing.

I know at least 2 implementations that are following the letter of the spec (and another one that have since been fixed to do the opposite of what the spec is saying), which results in occasional glyph clashes and overall in MathKerning being applied differently across implementations.

I think the spec should be clarified here to use more precise wording.

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: f0076fd2-52b0-2989-3142-fd9e456b9514
• Version Independent ID: 4aef8fa3-2ad3-7933-5a77-0a7473e66112
• Content: MATH - The mathematical typesetting table (OpenType 1.9) - Typography
• Content Source: typographydocs/opentype/spec/math.md
• Service: typography
• GitHub Login: @PeterCon
• Microsoft Alias: alib

[apoorvpotnis]

Is any progress being made on this issue?

[tiroj]

@khaledhosny

I think the spec should be clarified here to use more precise wording.

Could you perhaps draft some wording that accurately reflects what the MS math handler and XeTex are doing, which seems to me correct? I suspect one reason there has not been any movement on this issue is that there might not be anyone at Microsoft actively engaged in math layout work at the moment. Murray Sargent has retired, and the various people who worked on aspects of math layout back when it was first introduced and we made Cambria Math are all now dispersed on other projects.

[apoorvpotnis]

@tiroj Would it be appropriate/beneficial to file a bug report to the Word or MS Office developers, as those are the places where active development is taking place? MS Office teams would probably have the people who work on the math engine implementation, no?

[tiroj]

I am corresponding with @davidmjones who implemented OT math layout in XeTeX, and he reminded me of email exchanges with Murray Sargent and @SergeyMalkin about this topic back in 2020. Sergey was able to confirm at that time that what XeTeX is doing is correct, so having the spec reflect this would be great.

[davidmjones]

Could you perhaps draft some wording that accurately reflects what the MS math handler and XeTex are doing, which seems to me correct?

I think changing "minimum" to "maximum" is all that's needed. When both kerns are negative, the maximum is the same as the kern with the minimum absolute value, which is presumably where the confusion arose.