You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ).
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 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.
The text was updated successfully, but these errors were encountered:
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.
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
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
andminsize
entries in the mo attribute tableThe text in 3.2.5.7 Stretching of operators, fences and accents, stating:
3.2.5.7.1 Example of stretchy attributes
maxsize=100%
capping at the unstretched glyph sizeThe 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 thestretchy
andsymmetric
on/off considerations as they (can?) lead to a differentT
computation, and hence a different base for the minsize/maxsize percentage value.The text was updated successfully, but these errors were encountered: