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

Fix handling of mrows that look like \left...\right to be texClass INNER. (mathjax/Mathjax#2584) #568

Merged
merged 1 commit into from
Mar 8, 2021

Conversation

dpvc
Copy link
Member

@dpvc dpvc commented Dec 16, 2020

This PR removes the check that there either be no previous element or that it be marked as fnOP in order for an mrow to be marked as TEXCLASS.INNER. That was incorrectly preventing \left...\right constructs from being treated as the correct class.

With this PR, f\left(x\right) will be spaced as it is in actual TeX (with a bit of extra space between the f and the open parenthesis). It also means that

<math>
  <mi>f</mi>
  <mrow>
    <mo>(</mo>
    <mi>x</mi>
    <mo>)</mo>
  </mrow>
</math>

will also be spaced the same way. Some may object to that. There are several ways to prevent it. One would be to set the mathMLSpacing property to true on the output jax. Alternatively, you can modify the input to be

<math>
  <mi>f</mi>
  <mrow data-mjx-texclass="ORD">
    <mo>(</mo>
    <mi>x</mi>
    <mo>)</mo>
  </mrow>
</math>

or

<math>
  <mi>f</mi>
  <mo rspace="0">&#x2061;</mo>
  <mrow>
    <mo>(</mo>
    <mi>x</mi>
    <mo>)</mo>
  </mrow>
</math>

One could also write a MathML input jax post-filter to add the data-mjx-texclass="ORD" to recover the earlier behavior.

Resolves issue mathjax/MathJax#2584.

@dpvc dpvc requested a review from zorkow December 16, 2020 15:34
@dpvc dpvc added this to the 3.1.3 milestone Jan 31, 2021
@zorkow
Copy link
Member

zorkow commented Feb 9, 2021

This could be related to the issue @pkra had flagged in his visual output comparison.
Personally I like it, as it will make easier on the SRE site. But I will first test a bit before I approve.

Copy link
Member

@zorkow zorkow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm.

@zorkow
Copy link
Member

zorkow commented Mar 8, 2021

One idea struck me: SRE adds invisible function applications during enrichment. We could set rspace="0" to make the visual difference between the original and enriched less pronounced.

@dpvc
Copy link
Member Author

dpvc commented Mar 8, 2021

We could set rspace="0" to make the visual difference between the original and enriched less pronounced.

That would probably be a good idea in the cases where the <mrow> for the fence was added by SRE (but not on the invisible apply in general, a that can cause wrong spacing in other situations).

@dpvc dpvc merged commit 684c182 into develop Mar 8, 2021
@dpvc dpvc deleted the issue2584 branch March 8, 2021 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants