Gecko bugs blocking use of Native MathML in MathJax

(I post this on Mozilla's MathML mailing list and cc' other people 
potentially interested)

Dear all,

As you know, MathJax will be enabled by default in Wikipedia in a near 
future. I've recently been looking again at the major bugs that prevent 
Gecko's native MathML to be enabled by default in MathJax and how to fix 
them. I give a summary below, based on the analysis of MathML code 
generated by MathJax from LaTeX 
(https://github.com/mathjax/MathJax/wiki/MathML-Support-In-Browsers) and 
on other discussions with the MathJax team & users. Most of the issues 
were already mentioned in my "Roadmap" blog post 
(http://www.maths-informatique-jeux.com/blog/frederic/?post/2012/09/01/Mozilla-MathML-Project%3A-Roadmap). 
Some workarounds can easily be integrated in MathJax's code and I've 
prepared some patches for Gecko in order to fix the major issues. I 
believe linebreaking support can be ignored for now, it is not enabled 
by default in MathJax's SVG/HTML-CSS output modes so I don't think that 
should be a strict requirement for native MathML either. Thus I guess it 
will only remain to fix bugs like support for @rowspacing/@columnspacing 
or better implementation of token elements.

Unfortunately, I don't expect to have much free time to work on Gecko's 
MathML support in the upcoming year. So unless we find a way to fund 
Gecko's MathML project, other volunteers will have to help. BTW, for 
those who haven't read this article from Adam Hyde: 
http://toc.oreilly.com/2012/11/math-typesetting.html. I'm not sure that 
it will really help Gecko's MathML developments at the moment because 
the publishing industry seems rather focused on Webkit. Perhaps 
FirefoxOS will make more e-book companies interested in Gecko's MathML 
for EPUB, but that will clearly not happen soon. Anyway, let's consider 
the list below and hope we will figure out a way to achieve the goal of 
making Gecko's MathML enabled in MathJax again.

1) Font support:

- Using fonts from MathJax's CDN: 
https://github.com/mathjax/MathJax/issues/301
- Stretching braces with MathJax fonts: 
https://bugzilla.mozilla.org/show_bug.cgi?id=732832

The rendering without math fonts is still our worst bug. I trust this 
can be fixed by using fonts from MathJax's CDN. It will still possible 
that the horizontal braces are not stretched but I expect this issue to 
be solved when the MathJax fonts are updated to use only one glyph for 
the middle part of braces.

2) Spacing:

- @rowspacing/@columnspacing: 
https://bugzilla.mozilla.org/show_bug.cgi?id=330964
- negative mspace@width: https://bugzilla.mozilla.org/show_bug.cgi?id=717546
- width of <mspace>/<mpadded> within <mtable>: 
https://bugzilla.mozilla.org/show_bug.cgi?id=459363

Support for @rowspacing/@columnspacing is a natural continuation of bug 
731667, that Quentin almost fixed. Regarding the second bug, I have a 
small patch that adds partial support for negative mspace@width and will 
cover MathJax's use cases. I've recently submitted a fix for the third one.

3) Linebreaking:

- https://bugzilla.mozilla.org/show_bug.cgi?id=534962

This will certainly be too much work to do for volunteers. Gecko 
actually has a basic linebreaking algorithm for direct children of the 
<math> element but MathJax always adds an explicit <mrow> ancestor (to 
workaround measuring issues with the <math> element) so linebreaking is 
never applied.

4) Operator Stretching:

- Embellished operator regression: 
https://bugzilla.mozilla.org/show_bug.cgi?id=687807

The easiest way to fix this bug would just be to revert some changes I 
made to implement mrow-like embellished op. Karl also has some 
suggestions to refactor our data transmission, but that will be more work.

5) Tabular elements:

- support for mlabeledtr: either 
https://github.com/mathjax/MathJax/issues/356 or 
https://bugzilla.mozilla.org/show_bug.cgi?id=689641
- columnalign: https://bugzilla.mozilla.org/show_bug.cgi?id=491384

Davide prepared a workaround for the lack of mlabeledtr support and I 
think this will be ready for MathJax 2.2. However, we will still need to 
fix incorrect width computation within <mtable> (see 2 above and 6 
below). There's already a workaround for the columnalign bug in MathJax 
and I hope Quentin's work on 731667 will fix it anyway.

6) Token elements:

- width of token elements within <mtable>: 
https://bugzilla.mozilla.org/show_bug.cgi?id=415413
- @mathvariant: https://bugzilla.mozilla.org/show_bug.cgi?id=114365
- rendering of primes: https://bugzilla.mozilla.org/show_bug.cgi?id=442637

I hope the first will not be too difficult to fix, but I haven't looked 
at the details yet. If fonts from MathJax's CDN are used, then common 
mathvariant characters necessary for MathJax will be displayed 
correctly. I believe MathJax uses an <msup> for the prime (as 
recommended by the MathML REC) and so Gecko must handle this properly. 
All these bugs could essentially be addressed by moving some treatments 
of MathML token elements from nsMathMLTokenFrame to nsTextFrame (see bug 
785956).

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic