Characters partially disappear when zooming on iOS devices

[loopspace]

Issue Summary

When using "pinch to zoom" on an iOS device (iPad/iPhone) on a page with MathJaX rendered as "CommonHTML" (such as the MathJaX test page) then characters flicker and if the zoom is stopped in the right place then they can (partially) disappear.

This does not happen with the SVG renderer.

Steps to Reproduce:

1. Open up the samples page https://www.mathjax.org/#samples on an iOS device - I tested with safari and chrome. Make sure it is set to render as "CommonHTML"
2. Use the "pinch to zoom" facility to zoom in on a piece of Mathematics. You should see a noticeable flicker.
3. You can "catch" the flicker in the act if you stop the zoom carefully.

Although most of the time it's really obvious that something weird is happening, if the zoom is just right then it can turn a plus into a minus.

Technical details:

• MathJax Version: 2.3 (latest commit: f3aaf3a)
• Client OS: iPadOS 13.4.1, also confirmed on an iPhone (iOS version unknown)
• Browser: Chrome 81.0.4044.124, Safari (latest version - can't find version number)

Supporting information:

Screenshots from the MathJaX samples page.

[dpvc]

We have seen this with Safari, and other WebKit based browsers. See for example this post. We do not currently know of a work-around. This summer we are working on the font support for v3, and will be looking into this issue at that time.

[llui85]

There appears to be something weird going on with the fonts. See this codepen, in which I have copied the font declarations from MathJax and just displayed some text. I can still reproduce this issue on iOS with just the fonts. (Note that you can't always reproduce it inside the iframe, but if you enter debug view (fork it), then you can see it).

[llui85]

I converted one of the fonts to TTF and then back to WOFF2, and this seems to have fixed the issue. Could something be wrong in the font generation process?

Edit: If I use the source font directly, I still have this problem. Are these files manually generated?

[llui85]

@dpvc
How are the TEX fonts generated?

[dpvc]

I converted one of the fonts to TTF and then back to WOFF2, and this seems to have fixed the issue. Could something be wrong in the font generation process?

The MathJax fonts have some font metrics set in an unusual way in order to be able to position them more easily in math formulas. Your conversion process probably reset those parameters, so they worked better as text fonts.

We are in the middle of doing a font overhaul and will be replacing the MathJax fonts with newer versions. We hope to address this problem at that time. Doing so may require changes to MathJax internals, however.

[LLWest1]

Is this font overhaul project still being planned? Will this include support for more fonts, similar to MathJax 2.0.
"We are in the middle of doing a font overhaul and will be replacing the MathJax fonts with newer versions. We hope to address this problem at that time. Doing so may require changes to MathJax internals, however."

Is there a planned fix for the iPad rendering issue? (I can provided examples if needed). With 3.1 we are seeing issues with MathJax cutting of the screen on IPad iOS. We also have a preference for sticking with our existing 2.0 font choice.

Will this include support for more fonts, similar to MathJax 2.0.

[dpvc]

@LLWest1:

Is this font overhaul project still being planned?

Yes, but it is taking a bit longer than expected. It looks like it should be released this summer, with some pieces being available for testing earlier, perhaps. We currently have a stix2-svg branch that includes the full STIX2 font set for SVG, but it is designed for server-side use at the moment, as the fonts and font data needs to be broken up into smaller pieces so that you don't have to download the whole font and its data up front. The tools for doing that are coming along.

Is there a planned fix for the iPad rendering issue?

That should be resolves as part of this, but there is no separate patch planned. This issue should only affect CommonHTML output, so you could switch to SVG output to avoid the problem.

Will this include support for more fonts, similar to MathJax 2.0.

Yes, it should, and it will also include making the font tools available so that you could make the needed data for your own fonts, if you wish.

[mt4c]

Setting the css will-change property to "will-change: opacity;" or "will-change: transform;" seems to solve the issue.
Get the idea from https://stackoverflow.com/questions/52655475/why-is-safari-cutting-off-the-top-of-this-text , but seems the opposite way works.

[dpvc]

@mt4c, thanks for the tip. It seems that setting one of these two starts a new "stacking context" (see the Mozilla documentation here, in particular the description of the half way down the page), and that seems to be what does the trick. I tried other techniques that start a stacking context, but by themselves, they don't do it.

That page suggests that this is not recommended for leaving on in a stylesheet, which is what is necessary for Safari, so I'd recommend using a "WebKit-only" CSS wrapper. For example,

  @supports (-webkit-marquee-repetition:infinite) and (object-fit:fill) {
    mjx-container mjx-c::before {
      will-change: opacity;
    }
  }

works to select only Safari (and not Chrome) for this change, and to apply it only on the characters themselves.

Again, thanks for the solution, here. I would not have found this myself (and didn't).

[dpvc]

I've made a PR with this solution.

[mt4c]

@dpvc I read the MDN document and follow the link https://dev.opera.com/articles/css-will-change-property/ in stacking context page (following the will-change description).
Found out that "transform: translateZ(0);" also does the trick. This enables the GPU acceleration.

[dpvc]

@mt4c, thanks for the follow up, and the pointer to the interesting article. I had tried some transform values, but didn't think to try that one. Thanks. There are also new developments in the PR comment list. I will revise the PR based on that. I'm not sure whether to use your transform property or the original will-change: opacity, as I'm not sure which one uses more resources. My gut feeling is that will-change: opacity may be less intensive. With this new information about what is actually happening under the hood, I will see if I can make a better PR.