MathML support for MathJax and complete configuration through kernel

[poke1024]

This change adds MathML as an input format option to Jupyter's MathJax and, more importantly, a future proof way for kernels to completely configure MathJax to their specific needs.

MathML as an alternative input to the Jupyter defined default TeX input is necessary for kernels like Mathics (https://github.com/mathics/Mathics) which output everything as MathML and do complex reshuffling of the MathML XML nodes that is not possible on a TeX input layer (like having pictures and svgs in the exponents of a formula). In addition, MathML should really be an input option for kernels which opt for that format.

I recently created a PR for Jupyter 5 trying to solve this MathJax configuration via a config file entry (#1409) and it was a start, but this solution now proposed is, I believe, the proper and correct one. @minrk, I'm sorry for starting that former change without trying to fix the problem in the correct way first.

With this new PR, MathJax is not configured until the kernel has been asked which MathJax configuration it really needs. After a kernel has provided that information via kernel_info (see addition of mathjax in kernel_info proposed at jupyter/jupyter_client#161), MathJax is then configured for that kernel. If the kernel does not provide any information, the standard Jupyter configuration is used.

Since MathJax was already configured to initialize late (though the call of MathJax.Hub.Configured()), the delayed init is not a problem implementation-wise.

The one drawback of this PR for Python and TeX-mode MathJax users will be though that MathJax will only be loaded after the kernel has started up and provided its info. Currently, MathJax is loaded instantly (through the script tag in the notebook html template), thus rendering happens instantly. With the new solution, rendering can be delayed for a couple of seconds until the kernel is up and running.

The configuration happens in a differential way. Jupyter sets a default configuration, then everything the kernel delivers as configuration is merged into this default configuration.

MathML support is provided through changing setupbase.py and adding the necessary files for MathML input.

[takluyver]

I still don't think Mathjax configuration should be selected by the kernel. Mathjax expressions are also often in Markdown cells, which are not affected by the kernel - it would be weird if they behaved differently depending on the kernel you use. Other relevant considerations might include what browser the user wants to use and accessibility needs - neither of which the kernel is in a place to know.

[rgbkrk]

This does at least bring up the point that the MathJax configuration is tilted towards whatever is implemented in the currently running notebook, not part of the notebook spec. That does make it difficult for those that render notebooks (e.g. GitHub, nbviewer) as well as introducing inconsistencies between notebook versions.

[poke1024]

The request behind this PR is really just MathML input support for Jupyter's default MathJax configuration. The dynamic configuration via the kernel is an (over the top?) attempt to generalize this. Maybe this introduces more problems than it solves.

So, would doing a PR proposing to switch from the current TeX-AMS_HTML configuration to the TeX-AMS-MML_HTMLorMML configuration (see http://docs.mathjax.org/en/latest/config-files.html#the-tex-ams-chtml-configuration-file) as default be the saner and better option then? I would be very happy with it, as it would solve the Mathics problem that motivated this PR.

[minrk]

How are you getting MathML rendered on the page with your kernel and TeX-AMS-MML_HTMLorMML? Is it declared as HTML output? While MathJax may handle it, we should make sure that MathML isn't being identified as latex in any way at the notebook level.

[minrk]

Also, PRs in general should be made against master, not 4.x. We may backport to 4.x as appropriate (possibly not this), but all PRs should target master unless they are bugfixes that do not affect master.

[poke1024]

Yes, MathML is basically HTML (see https://en.wikipedia.org/wiki/MathML). All these special MathML tags have to always be embedded in surrounding <math> tags, so the MathML stuff is clearly delineated from the rest of the document (and the LaTeX content, for that matter, which must not be embedded in <math> tags and must not contain <math> tags itself).

Of course, the MathJax guys would know best, and I'm not a MathJax/MathML expert by any means, but from what I see and understand, the formats are clearly separated, since one is custom HTML with special tags and the other happens in the text content of regular HTML nodes.

Using the TeX-AMS-MML_HTMLorMML configuration for MathJax, all <math> tags in a document are simply grabbed and rendered and the LaTeX rendering in the rest of the document is handled separately from this.

It's worth noting that some browsers, most notably Firefox, have builtin MathML support, and will render <math> tags and MathML even if MathJax is not installed. So in fact Jupyter running under Firefox already basically behaves like MathJax with the added MathML support would. You can output <math> tags in the HTML there and it renders math.

The only potential problem with TeX-AMS-MML_HTMLorMML in my opinion might be AMS (AsciiMath), which could be configured to some obscure delimiters so as to be effectively disabled (see http://docs.mathjax.org/en/latest/asciimath.html). Sadly there's no standard MathJax configuration that only supports TeX and MML, you always get AMS in the bundle (see http://docs.mathjax.org/en/latest/config-files.html).

So is this, i.e. switching to TeX-AMS-MML_HTMLorMML, something that would be worth doing a new PR on master?

[minrk]

@poke1024 yes, I think that PR is worth doing. I still need to do some reading about exactly what the implications of the changed config would be, but it's certainly reasonable enough for a PR.

[poke1024]

Closing this, as a new PR on master will continue this.

[poke1024]

This has been succeeded by #1565.