Upgrade MathJax to 2.7.2 and update config

[rgbkrk]

As much as possible, our custom build of mathjax electron should match the TeX-MML-AM_CHTML config with MathJax. That's certainly not the case right now as I found out in nteract/nteract#2350

/cc @mpacer

[rgbkrk]

The config for TeX-MML-AM_CHTML is a little insane, this is no small feat to bring into mathjax-electron. Makes me wish we could use the CDN (for now) when online and then fallback to the electron one otherwise.

[rgbkrk]

And of course that one is insane. It's literally every option. From MathJax's Getting Started

Note: the configuration file TeX-MML-AM_CHTML is a great way test all input options at once.

[lgeiger]

I think TeX-MML-AM_CHTML is a bit overkill. Jupyter Notebook and Lab use TeX-AMS-MML_HTMLorMML-full,Safe.

The Safe looks like a good addition, preventing javascript execution inside equations.

For input I don't think we need to support MathML and AsciiMath in nteract unless people are expecting this feature in the notebook context.

Using MathML for the output wouldn't make much sense for us since Electron and Chrome don't support it. I would also advocate against the HML-CSS fallback since it mainly targets legacy browsers.
In my opinion this leaves us the choice between CommonHTML and SVG output. I originally chose SVG because of its faster rendering compared to CommonHTML and it can't suffer from font-related issues. The downside is that output can't be copied and pasted. Additionaly it has some resizing issues with tables and equation numbers. CommonHTML is the default renderer of MathJax and also looks like a good fit for us. The only slight downside is the possibly slightly slower rendering speed. For more information see http://docs.mathjax.org/en/latest/output.html.

Either way I feel we shouldn't be using the combined configuration since they bundle the files which would be otherwise loaded on demand. This improves loading times over a CDN but, I don't think is useful in our context.

Additionally I think we shouldn't included the a11y extension since it would add another 2.4 MB to the bundle. Currently we also don't include the MathMenu and disabled the status messages (which for me tend to be more distracting than helpful). Jupyter and mathjax-electron also sets some additional config options which we should still keep: https://github.com/jupyterlab/jupyterlab/blob/71a18ae0bb79acd6e0af2b8fffc691a8c756fd78/packages/mathjax2/src/index.ts#L75

[rgbkrk]

I like your reasoning, plan, and outline @lgeiger.

[lgeiger]

What do you say, CommonHTML or SVG?

[rgbkrk]

Since most of the rendering is controlled by React before it gets to MathJax, I feel like CommonHTML's speed limitation could be less of an issue. Reading about the CommonHTML output preprocessor, they seem to claim speed as one of its virtues:

[The CommonHTML output processor] is MathJax’s primary output mode since MathJax v2.6. Its major advantage is its quality, consistency, and speed as well as support for server-side generation.

Reading a bit more, the SVG mode is faster than the HTML-CSS not necessarily the CommonHTML output processor.

[rgbkrk]

What do you think of the loading of fonts for CommonHTML?

[lgeiger]

Maybe I misread the docs since CommonHTML is also HMTL-CSS based, there are 10x performance improvements expected anyway when moving to MathJax v3 so let's don't get caught up benchmarking. Let's try CommonHTML.

What do you think of the loading of fonts for CommonHTML?

There are some LaTeX glyphs that are not covered by the included fonts these glyphs are then approximated by combining multiple character which can sometimes mess up spacing. For SVG this is not a problem since math is rendered as paths. Anyway since CommonHTML is the default renderer this can't be that big of a problem.

[lgeiger]

One thing to check is the skipStartupTypeset setting since with @nteract/mathjax reopened notebooks may not be rendered.

[rgbkrk]

What I'm curious about for fonts is if we should load the fonts in advance like we do with Source Code Pro in Desktop.