[HTML-CSS] Bug: Horizontal line on radical /or sqrt sign broken or detached under Chrome for large zoom levels

[mjmg]

Issue Summary

For an equation containing a radical or sqrt sign, the horizontal line is broken or detached when I zoom in under Chrome.

This has been noticed before: http://meta.math.stackexchange.com/questions/12160/rendering-a-beautiful-square-root-with-mathjax

Steps to Reproduce

1. Load http://meta.math.stackexchange.com/questions/12160/rendering-a-beautiful-square-root-with-mathjax under Chrome and Firefox.

2. Compare the rendering of the radical sign under high magnification levels

This is a bug because the issue exists only in Chrome but Firefox renders the radical sign under high magnification better.

[dpvc]

The link you refer to on StackExchange is actually about whether the vinculum (the horizontal line over the radicand) has a small vertical line at its right-hand end or not, though there is one comment that refers to your issue.

You are right that under high magnification there can be a break in WebKit browsers in the HTML-CSS output. The CommonHTML output should work better for you, so one work-around would be to switch to that.

[ghost]

I would like to re-open this issue. Although the OP didn't really explain it well, this is happening for me on Windows 10 Pro (Version 1903) and Chrome 80.0.3987.163 (64 bit). This is how things look for me when scaling the math to 300% via the context menu (browser zoom level is 100%): And I think the problem with the root symbol is obvious.

This makes me wonder: how was this implemented and why could this not be implemented using what I think is the 'native' LaTeX version (with the longer version of the root symbol)? Seems to be implemented the same way for the fraction line to me. Both of them seem to be a little bit thicker than the standard LaTeX ones as well. The horizontal root line (viniculum) seems to be thicker than the root symbol itself

Edit: Just tried it out under Firefox 75.0 and it basically shows the same behaviour (although the separation is a bit less visible):

Edit 2: Both were rendered with the CommonHTML option

[dpvc]

how was this implemented and why could this not be implemented using what I think is the 'native' LaTeX version (with the longer version of the root symbol)?

This does use the LaTeX characters for the surd, and they do not include any horizontal portion (I'm not sure what you mean by "longer version"). There are 5 different discrete sizes for the surd, plus pieces to construct arbitrarily large ones when the radicand gets to be too tall. The top piece for that multi-character construct does include a horizontal portion, so perhaps that is what you are thinking of.

Getting the surd to match the horizontal line is a delicate operation, and one that is dependent on both the scale and the browser involved. Because the browser must align the display to the pixels on the screen, there are rounding issues that come into play, and those differ from browser to browser and scaling factor to scaling factor. Indeed, the exact same positioning dimension can be too large at some scaling factors and too small at others, so there is no perfect solution.

In this case, it would be possible to extend the horizontal line slightly to overlap the surd a bit more. That is already being done for the multi-character construction, so could be done here, as well.

Seems to be implemented the same way for the fraction line to me.

That is correct. Both are rendered using a CSS border property, and of the same thickness.

Both of them seem to be a little bit thicker than the standard LaTeX ones as well.

Yes, that is true. LaTeX was designed for the print medium, not screen display, and so is able to expect much higher resolution output (typical screen sizes where on the order of 96 pixels per inch until relatively recently, while publishing-quality print resolutions start at 1200 dots per inch and go up from there). In that setting, it is much easier to control the size of horizontal and vertical lines, because you have more resolution to work with. For a screen display, the horizontal lines for fractions and roots are typically 1 or 2 pixels high for normal text sizes, and there is no room for anything in between.

MathJax doesn't know the physical size of the final output (which will be based not only on the scaling factor, which is known to MathJax, but also on the browser's zoom level, which is not), so it can't tell how many pixels will be needed (or available) to make the horizontal line. Further, it gives the size in font-relative units (so that it scales with the size of the math), and so that is not directly in pixels in any case. If the width of the horizontal line is made too small, it can disappear at small sizes or zoom levels in some browsers. Because the math is supposed to work at both small and large sizes, and because small sizes are more common than large ones, MathJax makes the rule thickness somewhat larger than LaTeX does in order to prevent it from disappearing altogether. This means it is somewhat heavier than desirable at large sizes, but that is the cost of making it visible at small sizes.

The horizontal root line (viniculum) seems to be thicker than the root symbol itself

The two are produced by entirely different rendering technologies (text display versus CSS border), and the two have different characteristics during scaling. Text rendering is done using antialiasing techniques, which allow it to appear to have sub-pixel precision. Even with antialiasing, the horizontal and vertical directions do not work the same (there is more horizontal sub-pixel resolution than vertical resolution due to how colored pixels are generated on screen), so horizontal lines are particularly difficult to antialias. Horizontal (and vertical) lines can disappear at small scales, even with text rendering, which tries to minimize this. For example, at too small a scale, a minus sign can disappear, or a plus sign can lose its vertical portion and appear as a minus sign. So in general, thicker is better than thinner.

In the HTML-CSS output of version 2, we used (multiple overlapping) minus signs to generate a horizontal line in order to take advantage of the antialiasing so that it could match the surd character better, but that introduced its own problems (alignment was difficult to control, and the overlaps caused darker areas in the antialiasing, giving the result an uneven outline). It would be possible to use SVG lines with antialiasing (in those browsers that support that), but that also has its drawbacks. The current CSS border approach provides the best balance of the pros and the cons that we have found so far.

[rlanday]

Hi @dpvc, do you recall what the perceived drawbacks of using SVG rendering for this would be? I use MathJax primarily to render equations in my Anki flashcards and every time I see a square root rendered like this, it drives me crazy.

I’ve figured out that if I want to reproduce vector text or graphics from a PDF document (typically produced using LaTeX) on an Anki flashcard, I can select a rectangle in macOS Preview, save it as a PDF, and then run it through pdf2svg, which produces a SVG that exactly matches the original PDF. This tool does lose the selectable text since it converts each glyph to a path and seems to discard the information about the original character, but in terms of rendering, it looks very good, so this seems like a good approach for rendering square roots.

[dpvc]

@rlanday, what version of MathJax are you using? If it is v3 (the images above are for that, though the original issue was for v2), you can try adding the CSS

mjx-surd {
  transform: translatex(.02em)
}

to your stylesheet and see if that improves the situation for you for CHTML output.

If you are looking to get SVG versions of the equations, you can do that directly by switching to MathJax's SVG output rather than CHTML output.