[MATH] Confusion about displayOperatorMinHeight

[khaledhosny]

The description of displayOperatorMinHeight has:

Minimum height of n-ary operators (such as integral and summation) for formulas in display mode (that is, appearing as standalone page elements, not embedded inline within text).

But it has long been a source of trouble since Cambria Math sets it to a value that when respected results in too small display operators being selected: w3c/mathml-core#126

My own testing shows that Microsoft Word does not use displayOperatorMinHeight at all (setting it to any value makes no difference in which size of display operators is selected) and instead it seems to use the value of delimitedSubFormulaMinHeight to select the display operators size.

I’m speculating here, but I think it is a bug in Microsoft implementation and the wrong value in Cambria Math went unnoticed because of it.

I’m not sure what the spec should do here, but may be at least Cambria Math should be updated to use a reasonable displayOperatorMinHeight so that implmentations that follow the spec don’t have to implement various workarounds that render displayOperatorMinHeight almost useless.

---

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

[PeterCon]

I checked with Office engineers who confirmed that displayOperatorMinHeight is used in math "Display" mode, but not in inline mode.

[PeterCon]

Ah, but tracing back to code where the font data is being read, it appears Office may be reading displayOperatorMinHeight and delimitedSubFormulaMinHeight in the wrong order, which would account for @khaledhosny 's comment above:

instead it seems to use the value of delimitedSubFormulaMinHeight to select the display operators size.

[fred-wang]

@PeterCon Thanks for the feedback! (that seems consistent with previous discussion with Murray Sargent where apparently displayOperatorMinHeight and delimitedSubFormulaMinHeight were mixed up). So what's the plan forward here? Do you plan to fix Cambria Math? To fix Microsoft's implementation?

[PeterConstable]

My role in this is in maintaining the spec. I don't have a proposed remedy at this point. I have pointed out what I discovered to Office engineers and get their input on a proposed remedy.

If they don't want to make a code change, then that could suggest they might want a spec change, reversing the order of those fields. I would want to be very cautious, though, as I don't know what other existing implementations that could break.

Regarding Cambria Math, do I understand correctly that it has the delimitedSubFormulaMinHeight value set to what one would otherwise expect for displayOperatorMinHeight so that it provides the desired behaviour in Office (given the current bug)? If values are changed in Cambria Math, then older and newer versions of that font could behave differently. Desktop Office will use local fonts installed in the host OS, and a font fix might not get serviced in older OS versions.

[fred-wang]

Thank you @PeterConstable ; my understanding is that Cambria Math and Microsoft Word definitely have the parameters inverted compared to the spec. However, other math fonts and math rendering engines do follow the spec, albeit they have to somehow work around Microsoft's bug. I believe changing the spec would cause more harm than good.

Probably the solution would be to make sure that all the low-level APIs exposing MathConstants follow the spec, except when reading parameters from Cambria Math (up to a certain font version, if the bug is eventually fixed) where it would invert delimitedSubFormulaMinHeight / displayOperatorMinHeight values.