Skip to content
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

Closed
NSoiffer opened this issue Mar 31, 2020 · 6 comments
Labels
Accepted Issue has been reproduced by MathJax team Fixed Test Needed v2 v3 v3.1
Milestone

Comments

@NSoiffer
Copy link

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:
image

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
Copy link
Member

dpvc commented Mar 31, 2020

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
Copy link
Author

NSoiffer commented Apr 1, 2020

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 dpvc added Accepted Issue has been reproduced by MathJax team Ready for Development v2 v3 labels May 12, 2020
@dpvc dpvc self-assigned this May 12, 2020
@dpvc dpvc added this to the 3.1.3 milestone Jan 31, 2021
dpvc added a commit to mathjax/MathJax-src that referenced this issue Mar 24, 2021
@dpvc
Copy link
Member

dpvc commented Mar 24, 2021

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
Copy link
Member

dpvc commented Mar 24, 2021

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
Copy link
Author

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

@dpvc
Copy link
Member

dpvc commented Mar 24, 2021

Good point!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Issue has been reproduced by MathJax team Fixed Test Needed v2 v3 v3.1
Projects
None yet
Development

No branches or pull requests

2 participants