RE: Whither MathML support?

I hit send too quickly. Small correction: we supply XML, which includes the MathML, and the images of the equations created from the MathML,  to PLOS and _they_ convert it to HTML for online. They are working on implementing MathJax at PLOS but don't currently use it live.

Bill Kasdorf

VP and Principal Consultant | Apex CoVantage

p:

734-904-6252  m:   734-904-6252

ISNI: http://isni.org/isni/0000000116490786
ORCiD: https://orcid.org/0000-0001-7002-4786<https://orcid.org/0000-0001-7002-4786?lang=en>


From: Bill Kasdorf
Sent: Wednesday, September 06, 2017 3:39 PM
To: Ric Wright; W3C Publishing Business Group
Subject: RE: Whither MathML support?

I'll reply from the point of view of a major conversion and prepress vendor, Apex, which is the company I work for. And this is true of all of the other main prepress and conversion vendors that I know of. WRT:

  *   What is current publishing views on these questions?  Are the major publishers and/or journals actually using MathML?  It is not easy to find examples of the use of MathML (and most are very old) which suggests that it is not widely used.
Yipes!

What I think you're saying is "it is not easy to find examples of the use of MathML _in EPUBs_." That is true.

We create millions of equations as MathML, and so do our peers. It is fundamental to how we do math. To cite just one journal (admittedly the world's largest, PLOS), the first thing we do for _every equation_ is to convert it to MathML, no matter what format it comes to us in. All the uses of that math throughout the workflow, including images, are created from the MathML, and it is embedded in the XML that is the basis for the entire workflow. In the case of PLOS, as with many STM journals, that's JATS XML (almost all STM journals deliver JATS XML, though not all use it as the workflow format), but we also deliver all the content as HTML, and that includes equations. (I can't swear that the MathML makes its way into the HTML, but even if only images do, they were created from MathML.) That amounts to thousands of articles _per month_ published on a daily basis, a firehose of content. That's just one journal. The same thing is true of all book and journal content we create. All. All MathML. University of Toronto Press, for pete's sake? All MathML.

Virtually all math in scholarly publications now exists, at some point in the workflow, as MathML. The problem is that it almost never gets into EPUBs because the reading systems mess it up. (Plus almost no journals deliver articles or issues as EPUBs, though that is about to change. In fact Atypon, one of the world's leading hosting platforms for STM content, now owned by Wiley, will do that in their upcoming release. And it's all based on Readium.) We do what our customers tell us to do. So when they tell us not to put the MathML into the EPUBs, we don't. But we always have it.

I interviewed other prepress/conversion vendors and publishers for an article I recently wrote. Same story. They all have MathML for all their equations. Always. The MathML just doesn't get into the EPUBs.

So please help make the world safe for MathML in EPUBs!!!

--Bill K

Bill Kasdorf

VP and Principal Consultant | Apex CoVantage

p:

734-904-6252  m:   734-904-6252

ISNI: http://isni.org/isni/0000000116490786
ORCiD: https://orcid.org/0000-0001-7002-4786<https://orcid.org/0000-0001-7002-4786?lang=en>


From: Ric Wright [mailto:rkwright@geofx.com]
Sent: Wednesday, September 06, 2017 2:55 PM
To: W3C Publishing Business Group
Subject: Whither MathML support?

(This question is a little self-serving (well, maybe a lot self-serving :-) but just trying to leverage the deep experience and knowledge of this group.  Please feel free to ignore this post).

I know it's early days and it could be construed as more of a EPUB-specific issue, but Readium is hard at work (and making good progress) on Readium-2 which is envisioned as ultimately being a successor to the current Readium-1. One aspect we have been debating concerns support for MathML<https://www.w3.org/Math/>.  Do note that we are talking here of the rendering of MathML, not the semantic markup.

In Readium-1, we use MathJax<https://www.mathjax.org/> to provide support for MathML by injecting SVG.  We do this no matter which browser engine is being used and ignoring whether MathML is even present in the EPUB. Both decisions arose largely from expediency. We use the SVG output form from MathJax which is all paths, so completely inaccessible, but works very well.

Now, with Readium-2 (R2), we are considering two options:

  *   Only inject MathJax IFF the EPUB/WP has MathML (EPUB requires it be declared in the manifest) and the browser is considered poor at rendering MathML (which at present is all but Safari).
  *   Drop support for MathML entirely.
There are arguments to be made on both sides. MathML is required by the EPUB spec and R1 supports it so why go backwards?  OTOH, how much is MathML really used?  Plus, given the architecture of R2 it would not be too difficult to simply provide implementers the instructions of how to inject the necessary support so it could be an optional feature.

This discussion is of course primarily a reading-system issue, but what we would very much appreciate feedback from those willing to  provide it is:

  *   Given that the MathML spec seems to be, well, a bit stale (3.5 years since last update) what is the long-term view of its viability?
  *   Given the difficulty of making it accessible, does it make sense to try and provide markup that is accessible or just throw in the towel and provide bitmaps - or use a tool like MathJax on the server (or production time) and generate SVG or HTML/CSS then?
  *   What is current publishing views on these questions?  Are the major publishers and/or journals actually using MathML?  It is not easy to find examples of the use of MathML (and most are very old) which suggests that it is not widely used.
Thoughts?

Thanks in advance for any feedback.

Ric