Monday, November 18, 2013

The e-Writing Jungle Part 2: The MathML Impasse and the MathJax Solution

Back to LaTeX and MathJax and MathML and Python and Sphinx and IPython and R and Knitter and Firefox and Chrome and ...

In Part 1, I praised e-books done as LaTeX to pdf to the web, perhaps surprisingly. Now let's go the other way, to an e-book done natively on the web as HTML. Each approach is worth considering, depending on the application, as each has different costs and benefits.

Part 2: The MathML Impasse and the MathJax Solution

All we want is an HTML version with native support and beautiful rendering of mathematics. That's what HTML5 does, except for a small detail: many browsers (IE, Chrome, ...) won't display HTML5. The real problem is MathML, which is embedded in HTML5, and which is the key to math fonts in HTML5 or anywhere else. It's not just a question of browser suppliers finally waking up and flipping on the MathML switch; rather, successful MathML integration turns out to be really hard (seriously, although I don't really know why), and there are also security issues (again seriously, and again I don't really know why). For those reasons, the good folks at Microsoft and Google, for example, have now basically decided that they'll never support MathML. There's a lot of noise about all this swirling around right now -- some of it quite bitter -- but a single recent informative and entertaining piece will catapult you to the cutting edge, "Google Subtracts MathML from Chrome, and Anger Multiplies," by Steven Shankland.

The bottom line: Math has now been officially sentenced to an eternity of second-class web citizenship, in the sense that native and broad math browser support is not going to happen. But that brings us to MathJax, a JavaScript app that works with HTML. You simply type in LaTeX and MathJax finds any math expressions and renders them beautifully. (For an example see my recent post On the Wastefulness of (Pseudo-) Out-of-Sample Predictive Model Comparisons, which was done in LaTeX and rendered using MathJax.) Note well that MathJax is not just pasting graphics images; hence its output scales nicely and works well on mobile devices too. For all you need to know, check out "MathML Forges On," by Peter Krautzberger.

So what's the big problem? Doesn't HTML plus MathJax basically equal HTML5, with the major additional benefit that it actually works? Of course it's somewhat insulting to us math folk, and certainly it's aesthetically unappealing, to have to overlay something on HTML just to get it to display math. (I'm reminded of the old days of PC hardware, with separate "math co-processors.") And there are other issues. For example, MathJax loads from the cloud (unless it's on your machine(s), which requires installations and updates, and which can't be done for mobile devices), and the MathJax math rendering may take a few seconds or more, depending on the speed of your connection and the complexity/length of your math.

But are any of the above "problems" truly serious? I don't think so. On the contrary, MathJax strikes me as a versatile and long-overdue solution for web-based math. And its future looks very bright, with official supporters now ranging from the American Mathematical Society to Springer to Matlab. (Not that I'm a fan of Matlab any longer -- please join the resistance, purge Matlab from your life, and replace it with Python and R -- but that's a topic for another day.)

[Next: Python, Sphinx, ...]


  1. I fully acknowledge Matlab's weak points, but I've found it significantly faster than Python (unless using something like autojit or cython) and R. I've heard good things about Julia for technical computing.

  2. Julia is really interesting but the user community is pretty small at the moment. The big strength of R, and to a lesser extent Python, is the huge community of users and the correspondingly huge list of available packages.

    In my opinion the "killer apps" that tilt the balance in favor of R are Rcpp ( and Knitr ( The former makes including snippets of fast C++ code as easy as writing native R functions while the latter makes it seamless to include R code and results within markdown, HTML, or LaTeX documents.

    As far as the speed of R versus Python versus Matlab, my impression is that it's a matter of how experienced one is with each language's "performance idioms." Experienced R programmers write fast R code; experienced Matlab programmers write fast Matlab code. To put this another way, I used to think R was really slow. Now I know that I was doing really dumb stuff by (false) analogy to how I would have done something similar in Matlab. When the going really gets tough, though, there's no substitute for compiled code. That's why I'm so excited about Rcpp.