largeop="false" on integral causes overlapping limits

[jmitsdarfer]

Issue Summary

I just figured I'd report this because it seems like a bug, though perhaps there's some good reason for this that I don't know of. In order to avoid a really large integral/summation/product symbol in the sub or sup position, we use largeop="false". I noticed that largeop="false" causes crashing for the integral symbol (summation and product look fine) in MathJax. See below for an example.

PDF with <m:mo>∫</m:mo> (we don't use this tagging):

MathJax with <m:mo>∫</m:mo> (no crashing in this case; also the integral symbol is small as desired even w/o largeop="false"):

PDF with <m:mo largeop="false">∫</m:mo> (we use this tagging):

MathJax with <m:mo largeop="false">∫</m:mo> (crashing in this case):

MathML:

<m:msup><m:mrow><m:mi mathvariant="normal">e</m:mi></m:mrow><m:mrow>
<m:mo>&#x2212;</m:mo><m:mi>i</m:mi><m:msubsup><m:mrow><m:mo>&#x222b;</m:mo>
</m:mrow><m:mrow><m:mn>0</m:mn></m:mrow><m:mrow><m:msub><m:mrow><m:mi
>t</m:mi></m:mrow><m:mrow><m:mn>3</m:mn></m:mrow></m:msub></m:mrow>
</m:msubsup><m:mi mathvariant="normal">d</m:mi><m:mi>&#x3c4;</m:mi>
<m:msub><m:mrow><m:mi>&#x3c9;</m:mi></m:mrow><m:mrow><m:mn>10</m:mn>
</m:mrow></m:msub><m:mrow><m:mo stretchy="false">(</m:mo><m:msubsup>
<m:mrow><m:mi mathvariant="bold">Z</m:mi></m:mrow><m:mrow><m:mi>&#x3c4;</m:mi>
</m:mrow><m:mrow><m:mo stretchy="false">(</m:mo><m:mn>11</m:mn><m:mo
>,</m:mo><m:mn>10</m:mn><m:mo stretchy="false">)</m:mo></m:mrow>
</m:msubsup><m:mo stretchy="false">)</m:mo></m:mrow></m:mrow></m:msup>

and

<m:msup><m:mrow><m:mi mathvariant="normal">e</m:mi></m:mrow><m:mrow>
<m:mo>&#x2212;</m:mo><m:mi>i</m:mi><m:msubsup><m:mrow><m:mo
largeop="false">&#x222b;</m:mo></m:mrow><m:mrow><m:mn>0</m:mn></m:mrow>
<m:mrow><m:msub><m:mrow><m:mi>t</m:mi></m:mrow><m:mrow><m:mn>3</m:mn>
</m:mrow></m:msub></m:mrow></m:msubsup><m:mi mathvariant="normal"
>d</m:mi><m:mi>&#x3c4;</m:mi><m:msub><m:mrow><m:mi>&#x3c9;</m:mi>
</m:mrow><m:mrow><m:mn>10</m:mn></m:mrow></m:msub><m:mrow><m:mo
stretchy="false">(</m:mo><m:msubsup><m:mrow><m:mi mathvariant="bold"
>Z</m:mi></m:mrow><m:mrow><m:mi>&#x3c4;</m:mi></m:mrow><m:mrow><m:mo
stretchy="false">(</m:mo><m:mn>11</m:mn><m:mo>,</m:mo><m:mn>10</m:mn>
<m:mo stretchy="false">)</m:mo></m:mrow></m:msubsup><m:mo
stretchy="false">)</m:mo></m:mrow></m:mrow></m:msup>

Technical details:

MathJax Version: master - latest commit: MathJax.js v2.7.5
Client OS: Windows
Browser: Chrome Version 91.0.4472.114 (Official Build) (64-bit)
Renderer: HTML-CSS

[dpvc]

I'm changing the title of the issue, since in computer programming "crashing" refers to the program stopping unexpectedly. I was a bit alarmed when you said your input caused crashing, since that would indicate that MathJax stopped working. That is not actually what happens, so the change in title.

[jmitsdarfer]

@dpvc OK sorry, didn't mean to alarm you!

[dpvc]

The integral symbol is a peculiar one to work with. Because it is so slanted, if it used its full width, there would be way too much space between the integral and the letters that followed it. So the STIX fonts have the width of the integral sign at about half of the full width of the character, so that something like \int x will have the x reasonably close to the integral (it will extend over the top of the x. Where MathJax renders limits on the integral, it compensates for that using information from the bounding box of the integral sign as well as its stated width (half the bounding box width). But it turns out that v2 only does this when largeop is true. That should probably be considered a bug in v2 (v3 does it correctly). But that is why the scripts are overlapping the upper part of the integral (its width in the font is only half of the bounding box of the actual ink of the character).

You can work around this by using

MathJax.Hub.Register.StartupHook("HTML-CSS Jax Ready", function () {
  var HTMLCSS = MathJax.OutputJax["HTML-CSS"];
  var MML = MathJax.ElementJax.mml;
  var toHTML = MML.mo.prototype.toHTML;
  MML.mo.Augment({
    toHTML: function (span) {
      span = toHTML.call(this, span);
      if (!this.Get('largeop')) {
        if (span.bbox.rw > span.bbox.w) {
          span.bbox.ic = span.bbox.rw - span.bbox.w;
          HTMLCSS.createBlank(span, span.bbox.ic / this.mscale);
          span.bbox.w = span.bbox.rw;
        }
      }
      return span;
    }
  });
});

(additional code would be needed to support SVG output as well). This will make the adjustment for all characters, not just the integral, but I think that should be done in any case, and I don't think it will cause problems with anything else, but keep your eyes open in case it does.

In any case, the PDF output for when largeop="true" is incorrect. The largeop attribute doesn't mean to always use the large size, it means that the size should be large when displaystyle is true, and the small size when displaystyle is false. The script of an msup element should set displaystyle="false" automatically, so the small size should be used there (as in the MathJax output). But if you need to use largeop="false" to work around the PDF bug, the code above should allow that to work in MathJax as well.

[jmitsdarfer]

@dpvc Thanks for explaining the details of why we're seeing this. I think in this case we'll just leave how we're tagging these alone for the PDF but will create an automatic post-edit to remove largeop="false" for the MathML that'll be used for the MathJax. It sounds like that should solve the issue for now and also shouldn't cause any problem in the future if/when we eventually upgrade to v3. Thanks again!