1

Quick intro

I am working on a web project involving some intense math rendering, and I use latest MathJax version to do it. While I was adding content to one of my pages I noticed a really strange bug. It wouldn't be smart to copy-paste my webpage's full source code, so I simplified it down to this.

Source code

<html>
<head>
    <style>
        h3 {  font-size: 1.3em;  }
        h4 {  font-size: 1.2em;  }
        h5 {  font-size: 1.1em;  margin: 1em 0 0.5em;  }
    </style>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS_SVG"></script>
</head>
<body>
    <h3>H3 Header</h3>
    <h4>H4 header</h4>
    <h5>H5 header</h5> 0\(0\) 1\(1\) 2\(2\)
    <h5>H5 header</h5> 0\(0\) 1\(1\) 2\(2\)
    <h5>H5 header</h5> 0\(0\) 1\(1\) 2\(2\)
    <h5>H5 header</h5> 0\(0\) 1\(1\) 2\(2\)
</body>
</html>

Here is also jsFiddle playground.

Output

Screenshot of the resulting webpage

Problem

At some point SVG positioning and sizing messes up, then resets back to normal (look closely at the provided image).

Reproducing the bug

Bug is only present when SVG is used as an output mode. Looks and behaves differently in Chrome and Safari, didn't have a chance to check it with other browsers.

Bug changes its 'location' if you

  • add, remove or reposition headers
  • change font-size for any of the headers
  • change margin

Question

What is going on?

alex
  • 40
  • 7

1 Answers1

0

Webkit browsers like Chrome and Safari round sub-pixel values: Web-Kit and sub-pixel values, workaround?

In your case, you give the header font-sizes and margins in em units, and MathJax gives the width/height of the <svg> elements which contain the glyphs in ex units. Both may result in fractions of pixels (For example, in Firefox I get 15.4px for h5 margin-top, and 17.5333px for the height of the span surrounding the svg glyph. Chrome, with a different font, states 17.6px for margin-top, but 18px for the height of the span.)

Depending on the line you are in, the height of the span element around the MathML content might differ by one pixel, and it is positioned relative to the baseline of the font used for the surrounding line box. At the same time the glyph inside the svg is drawn in coordinates relative to the upper border of its bounding box and without further rounding of pixel fractions. As a result, the glyph base line may end up differing from that of the surrounding line box.

Is this a MathJax bug?

I would argue yes. The library renders what amounts to glyphs, but defines them as pure <path>s. If it leveraged the svg <font> and <glyph> elements, the usual font metrics like x height, dominant base line and so on would be defined, and vertical positioning would be much simpler for browsers.

While your issue shows up when MathML and regular text are used on the same line, it seems that Webkit rounding could even pose problems inside a formula, as this issue suggests.

ccprog
  • 20,308
  • 4
  • 27
  • 44