Spacing issue involving single '=' in fractions in mrow (with mathmlSpacing=true)

[NSoiffer]

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

<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
<script type="text/javascript" id="MathJax-script" async
   src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/mml-chtml.js">
</script>
 <script>
    MathJax = {
  chtml: {
    scale: 1,
    mathmlSpacing: true
  }
};
</script>

and the MathML is

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <mn>1</mn>
  <mfrac>
	<mo lspace="0" rspace="0">=</mo>
	<mn>2</mn>
  </mfrac>
  <mn>1</mn>
  <mfrac>
	<mo>=</mo>
	<mn>2</mn>
  </mfrac>
  <mn>1</mn>
  <mfrac>
	<mn>2</mn>
	<mo>=</mo>
  </mfrac>
  <mn>1</mn>
</math>

A codepen showing this at https://codepen.io/nms/pen/PoqLOpG

[dpvc]

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 <mo>=</mo> is not in an mrow, its default form attribute is infix. According to the operator dictionary, the infix entry for = has the default for lspace and rspace both equal to 5. So this equal sign should have thickmathspace spacing around it. That is where the extra spacing in the fraction is coming from.

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 lspace or rspace value (which seems contrary to the default nature of those attributes in the operator dictionary). WebKit does include the space within the fraction.

If I am mistaken about how the operator dictionary defaults apply (a distinct possibility), can you cite the section where that is described?

[NSoiffer]

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'.

[dpvc]

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 Max(rspace,lspace) idea. So I think that should resolve the issues here.

[dpvc]

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.

[NSoiffer]

I don't think you should fix in v2; it is good to have incentives to move to v3 :-)

[dpvc]

Good point!