Update minsize/maxsize percentage values to match MathML Core

[dginev]

As discussed in the MathML Core meeting on Feb 27 2024, the MathML 4 Full specification requires an update to match the algorithm specified by MathML Core (tracked at w3c/mathml-core#103 ).

The relevant MathML Core text is currently:
3.2.4.3 Layout of operators; item 2 - second bullet - item 5

Let minsize and maxsize be the minsize and maxsize properties on the operator. Percentage values are interpreted relative to T = T_ascent + T_descent.

Where T_ascent + T_descent - to our understanding in today's discussion - implies taking the percentage from the stretched size, rather than the unstretched size of an operator.

---

Relevant pieces of text that would need an update are:

• The maxsize and minsize entries in the mo attribute table

  • which currently state "Unitless or percentage values indicate a multiple of the reference size, being the size of the unstretched glyph."

• The text in 3.2.5.7 Stretching of operators, fences and accents, stating:

  • "operator's normal size in the direction or directions of stretching"
  • "then it can grow to be no more than three times its normal (unstretched) size."

• 3.2.5.7.1 Example of stretchy attributes

  • The example appears to show maxsize=100% capping at the unstretched glyph size

---

The practical consequence of the change is that if one wanted minsize/maxsize relative to the unstretched size of a glyph, it is better to use relative font size units, such as em. And not a percentage value.

Please send corrections if any of these details are inaccurate, as the T_ascent + T_descent computation is not fully understood by all participants. As a reporter here I still struggle fully factoring in the stretchy and symmetric on/off considerations as they (can?) lead to a different T computation, and hence a different base for the minsize/maxsize percentage value.

[dginev]

Action item, WG meeting 3/7/2024

I was tasked to report how MathJax currently renders the percentage values for minsize/maxsize, illustrated with a small superscript example. Here is a codepen and screenshot of the CHTML rendering:
https://codepen.io/dginev/pen/VwNaOzE

Notes:

• there appears to be a limitation with both em and % values where MathJax v3 won't scale down proportionately from the normal size (and maybe none at all in script positions). But scaling up appears more accurate.
• An easy test is commenting out the script tags and comparing to the browser rendering. Today the MathJax rendering matches Firefox, and not Chrome (i.e. it uses the unstretched size as a percentage base, as per MathML 3). The match is partial however, as Firefox will also be more precise with scaling down.
• aside: by default MathJax will emit em values in minsize/maxsize when converting from LaTeX, I also included those examples for reference.

The original source for the codepen was:
$$\Bigl( x^{\Bigl( y \Bigr)} \Bigr)$$

[dginev]

The group agreed on March 28, 2024 that no action will be needed for this issue, thanks to the upgrades landing in MathML Core seen here.

The changes in MathML Core lead to consistent behavior with the current Full spec text.