Asana Math superscript overlaps parenthesis

[pkra]

I recently stumbled upon a bad superscript rendering with the Asana fonts. The following example should reproduce this.

    <math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
      <msup>
        <mrow>
          <mo>(</mo>
          <munderover>
            <mo>&#x2211;<!-- ∑ --></mo>
            <mrow class="MJX-TeXAtom-ORD">
              <mi>k</mi>
              <mo>=</mo>
              <mn>1</mn>
            </mrow>
            <mi>n</mi>
          </munderover>
          <msub>
            <mi>a</mi>
            <mi>k</mi>
          </msub>
          <msub>
            <mi>b</mi>
            <mi>k</mi>
          </msub>
          <mo>)</mo>
        </mrow>
        <mrow class="MJX-TeXAtom-ORD">
          <mspace width="negativethinmathspace" />
          <mspace width="negativethinmathspace" />
          <mn>2</mn>
        </mrow>
      </msup>
    </math>

[dpvc]

Technically, this is not a bug with superscripts. If you look closely, the superscript has some backspacing (originally from \!\! in TeX) to move the 2 to the left. This is because the large parenthesis in the TeX font is considerably bowed, and it contains extra space on the outside (the vertical part of the parenthesis is actually centered in the glyph's bounding box). So with the TeX fonts, the superscript is very far away from the parenthesis. The TeXbook recommends this \!\! adjustment to account for it.

But the Asana large parentheses don't come in large enough sizes for this equation, and so they are the ones made from multiple characters. This makes them far less bowed than the ones from the TeX fonts. Further, they don't have the extra space around them that the TeX fonts do to center the vertical parts (if you look at the full equation, you will see that the parentheses on the right-hand side are practically touching). So the scripted 2 does not need the spacing adjustment in this case; but since it is in the MathML (not in MathJax rendering), this result is "correct".

This is one of the difficulties when trying to use different fonts that have different characteristics. You may recall that I mentioned in the past that some of TeX's spacing rules are actually carried out in the fonts. This is one of those situations, where the parentheses include extra space that isn't part of the ink of the glyph itself. Not all fonts do that. There are several other similar situations. When fonts don't have these, they will act differently.

The only solution I can see is either to remove the extra space from the TeX fonts, or modify the font data for other fonts to add the space. Neither is going to be easy, and will involve lots of hand work. If you remove the space from the TeX fonts, then the output jax would have to be modified to accommodate the changes in order to maintain TeX-quality output. My impression is that this would be complicated (but I can't say for sure without making a fuller catalog of the changes needed for the fonts). We already do some fontdata adjustments to other fonts (like for the integral symbol to make the spacing consistent with the TeX integral).

[pkra]

Ah! Thanks for the explanation.

I just checked and STIX, Neo Euler, and Latin Modern look fine, the Gyre fonts are a bit tight but ok. So it's really just Asana.

Maybe simply a won't fix / font "bug".

[dpvc]

The "expected behavior" was supposed to be the stand-in for "won't fix", but perhaps there need's to be another label for something that actually is "wrong" but that we aren't going to do anything about.

[pkra]

Ah, right. I guess my impression has been that "expected behavior" is mostly used for non-bugs (e.g, but of course it covers both. Personally, I would prefer to separate the two to catch won't-fixes and document them but that can be done on the docs issue tracker.