[tex4ht] [bug #340] Math issues in the ODF export

[Michal Hoftich]

Hi Bill,

> 
> For MathML I think it's better -- and sometimes more
> inter-operable -- simply to insert the full MathML namespace
> via the xmlns attribute in each <math> element and avoid
> prefixing altogether.  Of course, if inside a <math> element
> you want to insert something that is not MathML, that (a) is
> probably going to cause a problem somewhere and (b) would
> require either prefixing or inserting an xmlns attribute on
> each external subelement.
> 
> With HTML5 (as text/html) using prefixes will cause
> breakage.  Using an xmlns attribute on a <math> element in
> HTML5 is unnecessary but should go as unrecognized and be
> ignored by web browsers.  It is helpful when one wants the
> code to work for both the text/html and the
> application/xhtml+xml serializations of HTML5.  I'm guessing
> that this technique would be good for xtpipes.
> 

The prefixes are used only in OpenOffice output (and probably other
formats based on XML, I guess), not in HTML. I think that Eitan used
them because in the main xml file in the ODF file, everything is
prefixed. But each math instance is saved in standalone XML file and
included as picture from the main document, so it seems that prefixing
is not necessary. At least in the examples I've found, the prefixes
weren't used.

We still don't have HTML5 output unfortunately - basic structure
shouldn't be that hard to support, but what about new semantic or
accessibility attributes. Interesting ideas are contained in Scholarly
html format, although it is little too much prescriptive for my taste.
For example, for every math instance, annotation in TeX format is
required. This is doable in tex4ht, but not easy.


> 
> And, alas, failing to include presentation mathml in the
> html namespace was a way to make support of mathml in web
> browsers have secondary importance.  There are problems in
> browser handling of HTML5 that result from having MathML be
> external.  For example, a comma following an inline <math>
> element may wind up on the following line, whereas a comma
> following an (inline) <em> element will not.
> 

Sure, it seems that no one who creates reading applications likes
mathml. Some issues in browsers can be at least fixed using Mathjax,
but this is not an option in office suites. 

Totally tragic is mathml support in Epub 3 readers, where mathml is part
of the standard. Those who support it, do it using Mathjax [2]. This was
painfully slow last time I tried one of such applications on my phone.

One interesting idea is to use Mathjax to convert mathml to html - it
uses some CSS tricks to display the math correctly. Mathjax is now
supported in Node.js [3], with cli tool for such conversion. I've played
with it a bit and created library for make4ht [4]. It can be used with
the following make4ht build file:


---------------
local mathjax_node = require "mathnode"

Make:htlatex{}

local format = "woff"
Make:match("html$", mathjax_node, {fontdir = format, fontformat = format})
----------------

It assumes that Mathjax fonts in "woff" format are stored in the "woff"
directory. You can see sample result here [5].

I was also able to compile the previous example to an Epub file, which
could be displayed in readers with modern CSS support. I also tried to
convert that epub file to kindle format, but it didn't work, as
expected.


Best regards,
Michal


[1] https://w3c.github.io/scholarly-html/
[2] http://docs.mathjax.org/en/latest/misc/epub.html
[3] https://github.com/mathjax/MathJax-node
[4] https://github.com/michal-h21/make4ht/blob/master/mathnode.lua
[5] http://michal-h21.github.io/mathjaxsample/sample.html