-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spacing issue involving single '=' in fractions in mrow (with mathmlSpacing=true) #2392
Comments
Right, the first two fractions are embellished operators, and so the spacing for the equal sign is used around the fraction. The last one is not, so the spacing for the equal sign is used around the equal sign itself. According to section 3.2.5.7.2 because the If there is somewhere in the specification that says you aren't to use the default spacing under certain circumstances, I don't recall seeing that. I see that Firefox does not use this spacing, but does show an explicit If I am mistaken about how the operator dictionary defaults apply (a distinct possibility), can you cite the section where that is described? |
This is a case of where the MathML spec is both not specific and probably misleading. So don't feel bad about interpreting them incorrectly; blame me or someone else for writing them poorly :-) I wrote those tests to see if my feeling about what should be done for the MathML Core spec respects what current implementations (mostly) do. My interpretation (and what most others did) is that the spacing rules apply inside of an mrow. The lspace/rspace of the first/last operator are essentially inherited by the mrow so that if there is an outer mrow, they are used by the outer mrow for spacing. The other way of looking at it (and what MathPlayer implemented) is that you look (recursively) at the first/last child for the lspace/rspace of that child. Either way gets you the same result, but one is top-down and the other is bottom-up. MathPlayer has one additional wrinkle that I'm going to recommend for MathML Core: when computing the spacing: instead of rspace(before) + lspace(after), do max(rspace(before), lspace(after)). Most of the time it won't matter, but there are a few prefix (maybe postfix) operators that have spacing on their "outside". In particular, differential d comes to mind. This rule means that not only will ∫f(x) dx look right, so will dy = dx because the rspace of '=' won't add to the lspace of 'd'. |
I have finally gotten the chance to fix this. It turns out not to be as hard as I thought it was going to be. I also implemented your |
PS, currently this is only fixed in v3. I'm not sure if I will back-port it to v2, where the fix will be a bit harder. |
I don't think you should fix in v2; it is good to have incentives to move to v3 :-) |
Good point! |
Fix MathML spacing rules for mo elements. (mathjax/MathJax#2392)
Issue Summary
This is related to #2391, but this is with

mathmlSpacing=true
. In this case, the problem is the spacing around the '=' in the denominator of the third fraction:In this example, for some reason the spacing around the '=' influences the width of the fraction in the last fraction, but not in the second fraction. The second fraction uses MathML's embellished operator rules and so the spacing around the second '=' is (appropriately) increased.
The header is
and the MathML is
A codepen showing this at https://codepen.io/nms/pen/PoqLOpG
The text was updated successfully, but these errors were encountered: