Big (N-nary) operators are at the wrong vertical alignment

[ronkok]

For big (N-nary) operators, STIX TWO, like other math fonts, has both a standard and an alternate glyph. The alternate glyph is used in what TeX calls displaystyle and what MathML calls display="block".

Some of the alternate glyphs in STIX TWO are at the wrong vertical alignment. They are placed entirely above the baseline. They should instead have a substantial depth (descender) below the baseline. The image below shows the glyphs for Unicode points U+22C2 and U+22C3.

Latin Modern gets it right. STIX TWO gets it wrong. The results are appearing in production. The Temml library has an open issue that is the direct result of this misalignment.

[tiroj]

Noted for fix.

[ronkok]

I've done some more investigation. Below is a list of characters that all have this problem.

LaTeX function	Character	Code Point
\bigwedge	⋀	U+22C0
\bigvee	⋁	U+22C1
\bigcap	⋂	U+22C2
\bigcup	⋃	U+22C3
\bigodot	⨀	U+2A00
\bigoplus	⨁	U+2A01
\bigotimes	⨂	U+2A02
\bigcupdot	⨃	U+2A03
\bigcupplus	⨄	U+2A04
\bigsqcap	⨅	U+2A05
\bigsqcup	⨆	U+2A06
\bigdoublevee	⨇	U+2A07
\bigdoublewedge	⨈	U+2A08
\bigtimes	⨉	U+2A09

The integration symbols and the summation symbol all look good.

[Enivex]

Note that in Latex (and other places) operators like this are always centered vertically regardless of how they appear in the font, so that's why this doesn't have any effect there.

Temml should probably do the same if possible in MathML?

See https://github.com/typst/typst/pull/1735 in the case of Typst

Edit: According to https://github.com/typst/typst/pull/1735#issuecomment-1642934374 you can set the symmetric property?

[ronkok]

Note that in Latex (and other places) operators like this are always centered vertically

I believe the same should occur in MathML. It does occur in Firefox. It's broken in Chromium and WebKit. It's a bug. Google has been very unresponsive to other MathML bugs that I have reported. I was hoping you might be able to help me work around this issue and get a good rendering even if they don't respond.

you can set the symmetric property?

Yes, I can set the symmetric attribute for an <mo> element, although it should not be necessary. These character code points are in the MathML operator dictionary, which states that they should have the symmetric, largeop, and movablelimits attributes pre-set to true. The alignment is still wrong. I have also done experiments with setting those attributes manually. It does not help.

This bug may have its origin in the MathML-Core specification. When I read section 3.2.4.5 Layout of operators, I note that part 2 is conditioned on the stretchy attribute and specifies an adjustment of the vertical alignment for stretchy elements. Part 3, regarding the largeop attribute, is silent regarding vertical alignment.

Indeed, I can achieve the correct vertical alignment in Chromium and WebKit by setting the stretchy attribute. But I then get the small glyph, not the large glyph. That's true even when I manually set the largeop attribute. The end result is that I can get the correct glyph or the correct vertical alignment but not both.

I intend to take the following steps:

1. Open issues with the MathML-Core spec and with both browsers. I do not expect much help from any of them.
2. Try for a CSS fix that enforces the correct glyph while stretchy is set. It would help if you could tell me the font-feature-setting that would select the large glyph. aalt?, ss01? other?
3. If I cannot enforce the correct glyph, I guess I'll use CSS to manually change the vertical alignment. That will cause a breaking change someday when the browsers finally get this right. I'd like to avoid that, but I may have no choice.

[ronkok]

Strike option 3 above. I have discovered that I can get proper rendering if the <munderover> element has the stretchy attribute and is a top-level element. That is, it must not be nested within a <mrow> element.

I consider that to be very odd behavior and I may go mad someday working around browser vagaries but at least I have a path forward.