Can you have an ebook format for education that doesn’t support math? (Note: it’s a rhetorical question!)
Math is pervasive, despite the common perception that it’s only for STEM. Even novels have been known to include equations from timetotime.
And yet consumerend MathML support in digital works is still lacking, despite two decades of work in W3C. If you want the whole story, Peter Krautzberger has written a fantastic article on the history of MathML and support in browsers that I’d highly recommend reading. I’m not going to attempt anything similar today, as there’s nothing of value a math neophyte like me could add.
Rather, what has me thinking MathML is the upcoming second EDUPUB conference, and the lack of consistent rendering, and voicing, of math in EPUB reading systems. In particular, how do we effect real change?
Why MathML
But first, if it needs justification, there are lots of good reasons why we need MathML, not least of which is that math equations are not pictures — despite the prevalent belief to the opposite among webgoers.
I think there’s a tendency to forget that the pictures you get in ebooks today have to come from somewhere, and authors aren’t drawing them by hand. The problem is that MathML on the backend doesn’t often see the light of day because support has been, and still is, so spotty. (I realize some people will have LaTeX behind the scenes, but assuming getting to MathML isn’t what prevents it being used in outputs.)
Math is a text format, so representing it as pictures is on par with adding pictures of headings or other text. Let me correct that, it’s worse than plain old text in images because describing a math equation is so much more complex. The alt text is rarely a onetoone representation of the text in the image.
To cite the simple example I put in the book, what does the description “square root of a plus b” translate into? There are two ways to read it. With MathML (and voicing), anyone could figure out the correct interpretation, as the equation becomes part of the DOM and can be walked over. Without… well, you’re at the mercy of a description.
Native support
Assuming you believe me that MathML is a key need for accessibility, why does native support in browsers, and by extension reading systems, matter so much? We’ve lived with plugins and polyfills this long, right?
While these solutions work for the web generally, neither represents a great solution for ebooks. Plugins, for example, simply aren’t viable for reading system apps. The reader has to use a browser to take advantage of them. And when you start putting restrictions on what devices and applications a reader can use, you ghettoize accessibility, which is what making accessibility a core tenet of a mainstream format like EPUB was intended to get away from.
To use Design Science’s plugin doesn’t mean only limiting yourself to IE9 and below (now that IE doesn’t support plugins), but means limiting yourself to only reading systems that directly run inside a browser.
Polyfills have greater range, but suffer a kind of impedance mismatch with ebooks and reading systems. For one, who implements the polyfill? Is it the reading system that lacks native support, or is it the content author who wants to ensure the ebook will render no matter the reading system?
And if it is the author, why is it incumbent upon them to integrate what is a rendering engine into their content? It’s bizarre — almost beyond words — for a standalone format, and barely more tolerable for regular web pages.
There are other technical reasons why native is better than code that has to be run at rendering time and/or live on top of the browser. Speed of rendering is a commonly cited one. Access to fonts another.
We’re lucky to have MathPlayer and MathJax to bridge the gap, don’t get me wrong, but ultimately the goal has to be integration into the core.
Fixing the equation
So what can be done to improve the situation?
What is interesting from reading Peter’s article is how MathML is treated as peripheral technology not worth investing resources into. I can see that preHTML5, but I’d have expected that view to have changed with support being integrated. It’s odd, to say the least, that unless volunteers are working on these implementations they go nowhere.
That said, this lack of priority also gives a possible clue about what needs to be done. Either the organizational disinterest in supporting math needs to change, or developers need to be financed to finish the work (even if they’re volunteers as far as submitting the code goes).
There is a persistent belief that MathML is underused, because images are what appear in web and EPUB content. An analysis of web markup isn’t going reveal much of anything about the amount of MathML that flows through publishing, for example, or how much is stifled before it ever makes it out the door.
It might be time for a concerted push by the large publishers and/or publishing organizations to raise awareness that treating MathML development as a peripheral need has to change. A little heft couldn’t hurt.
Barring that, funding a developer to finish the WebKit code might be another alternative. If it is as key to digital publishing for education as I believe, finding that money shouldn’t require moving mountains. How it would go over with the browser engine folks I couldn’t say, but I’m only out to speculate on options.
Maybe I’m being naive and have stars in my eyes, but now that MathML is a core part of HTML5, pushing support over the final hurdles seems like a goal everyone can share.
Of course, MathML rendering doesn’t mean MathML voicing, so there are still hurdles, but we have to start somewhere.
But before I go off too long on this, I’ll wrap up by expressing how frustrating it is to have more “potential” for accessible math than actual support.
When I can’t convince myself that I’d trust MathML rendering… and unformatted math is as inaccessible for sighted readers as pictures of math can be for blind… well, that’s how we get stuck in these cycles.
It’ll be interesting to see what comes at this next EDUPUB meeting, and whether a strategy for MathML hits the radar.
Tags: latex, mathjax, mathml, mathplayer

> It might be time for a concerted push by the large publishers and/or publishing organizations to raise awareness that treating MathML development as a peripheral need has to change. A little heft couldn’t hurt.
> Barring that, funding a developer to finish the WebKit code might be another alternative. If it is as key to digital publishing for education as I believe, finding that money shouldn’t require moving mountains. How it would go over with the browser engine folks I couldn’t say, but I’m only out to speculate on options.Are you aware of http://www.ulule.com/mathematicsebooks/?

Thanks for your kind words about my piece at Programming. I agree that such a serious, long term effort seems the only way for native support right now. But it is a much more difficult project idea to pitch to potential sponsors than a polyfill or plugin (which is hard enough). For example, a browser project still needs a serious dedication from browser vendors — architectural support, a long term strategy for the code contributions, and a path towards vendors taking ownership of the MathML code base. Then, it’s difficult to gain longterm sponsors for such a project because of the impression of making a “gift” to Apple, Google, Mozilla and Amazon. (That doesn’t mean I won’t work towards such a project.)
By the way, my favorite personal reason in favor native support is that math (and science) deserve to move beyond MathML 3 — just like HTML deserved to move beyond HTML 4 (or 5 ;) ). As good as MathML 3 is (and it is!), it is almost exclusively a conversion of printed mathematics. We have very few ideas right now what MathML 4 and 5 might look like, what a truly native expression of math on the web will look like. I’m eager to find out what people will come up with once they have MathML 3 at their universal disposal.

Thanks for your kind words for my company’s MathPlayer product. I just wanted to point out that while it is a plugin for IE, in that each user has to install it into their browser, it makes use of IE’s really robust extension mechanism. One installed, it runs at native code speed and operates much like the code behind native HTML elements.
My point in saying this is that Microsoft could take our code and integrate it into IE so it no longer needs to be installed by each user. This would give future versions of IE a powerful native MathML installation. It puzzles me that Microsoft doesn’t even care enough about MathML to do this.
The problem with Microsoft and the other browser makers is that they do not hear requests for MathML support from people, other than from us insiders of course. I don’t think most educators and AT people know enough about MathML to make such requests or they are not in the same world as the browser makers. As Frédéric Wang suggests, perhaps it is time for some kind of grass roots effort to get the word to them. However, publishers do understand about MathML as they’ve been using it internally for years. It is the education community that needs to be reached. Big companies like Microsoft and Google are very interested in supporting education. Education needs to be told what to ask for to get math support in browsers.

FYI — The MathFlow product from Design Science, which allows easy editing and manipulation of MathML equations, has been integrated with the latest version of Adobe FrameMaker 12. Adobe also has a new, less expensive XMLonly editor, FrameMaker XML Author 12, which supports this product. In either product, you can go into the XML code view of FrameMaker and see the XML display of MathML equations. Hopefully this will help spur acceptance.



10 comments
Comments feed for this article
Trackback link: http://matt.garrish.ca/2014/01/mathmlsupportinepub/trackback/