Mozilla MathML Project: Roadmap
By fredw on Saturday, September 1 2012, 18:45 - Permalink
That's not a secret, native MathML support is not really available in layout engines other than Gecko: Webkit implementation is not mature yet and still disabled in Chrome, Opera's CSS-based implementation is of really poor quality, Internet Explorer does not implement MathML at all. As a consequence, it does not really make sense to compare the different MathML supports to motivate Gecko's development. In constrast to the very limited interest of browser vendors for MathML, users have shown a great enthusiasm for reading and writing mathematical notations on the Web. Since I got involved in the MathJax project, I have been able to discover an increasing use of mathematics on the Web and related technologies (Wikipedia, e-books, handwriting recognition and many other use cases). When Firefox's native MathML was enabled by default on MathJax, we received important bug reports and enhancement requests, collected in some tracking bugs like MathML2 support, MathML3 support, MathML in MathJax, MathML demo pages. Hence I have preferred to base a roadmap for the Mozilla MathML Project on user feedback The table below summarizes what I think are the most important areas to work on in order to improve user experience. For each of these areas, I give the rationale and a more detailed description with recent, short-term and long-term work.
| Rationale | Detailed Description | |
|---|---|---|
| Font support | See for example about mathematical fonts. | The Fonts for Mozilla's MathML engine page has been reorganized and now includes a new test page, a Windows installer and quick instructions. Thanks to my brother François Wang, Web authors can use @font-face rules to workaround font installation issues. The MathML add-on is now fully compatible with Desktop and Android versions of Firefox. MathJax fonts are now well supported and we will have a complete support after MathJax fonts are updated. In the future, adding a generic support for Open Type fonts will at least offer support for Cambria Math, Neo Euler, STIX 1.1, Latin Modern Math, Lucida fonts and Asana Math. |
| Spacing | Esthetic of formulas, advanced layout. | Xuan Hu is currently working on a better computation of vertical metrics in <mpadded>. In view of this analysis of Browsers' rendering of MathJax's LaTeXToMathML tests, the most serious spacing issues are the lack of support for mtable@rowspacing/columnspacing and negative spaces. In the future, using the data from the Open Type MATH table could also give better positioning than our current heuristic TeX-based rules. |
| <mlabeledtr> | Labels, numbering and cross-references. | Labels, numbering and cross-references are essential for scientists
to publish papers or similar documents on the Web. Since Firefox 9,
authors can override our default rendering of
<mlabeledtr> (no label shown) via CSS rules... until
someone adds a complete
support for <mlabeledtr>. |
| Linebreaking | Reading on small screens, printing. | The Mozilla Corporation has recently concentrated some efforts on mobile devices (smartphones, tablets, e-readers, etc) for which linebreaking inside and around equations is important. This is also obviously necessary to correctly print pages containing mathematical formulas. BTW, some work is in progress to fix printing issues when @font-face is used. |
| Operator Stretching | Commutative diagram, chemistry formulas. | Stretching
operators in table cells is crucial to draw basic commutative
diagrams (e.g. those provided by the amscd package). More
advanced diagrams may need stretching
in diagonal direction. There is also a serious
regression that was found when the mhchem extension
has been implemented in MathJax. |
| Tabular elements | Advanced mathematical layout, code refactoring. | Quentin Headen has worked this summer on refactoring the <mtable> code and I hope he could use his work to implement mtable@rowspacing/columnspacing. In general, there is a lot of missing tabular attributes that are important for advanced mathematical layout. Probably related is the support for elementary math layouts that some people have asked on the MathJax mailing list and others voted for on Bugzilla. |
| Token elements | Better rendering of text in mathematical formulas, code refactoring. | Just as the tabular math code, the code for token elements needs a
serious rewriting. Ehsan Akhgari recently fixed a general issue with
token elements and I prepared a patch for
the <ms> element. In general, I think we should move special
treatments of MathML token elements to the style system (or at
least outside of layout/mathml/nsMathMLTokenFrame.cpp). This encompasses several
other text issues like support for
mathvariant, bad
measurement of text, rendering of
primes etc |
| Dynamic MathML | Interactive Web site, Javascript applications. | Clearly, many authors want to write interactive Web sites. This is also true for mathematics, as shown in various discussions on the MathJax mailing list and elsewhere. Unfortunately, we have a couple of bugs with dynamically modified MathML and the <maction> element is not completely implemented yet. A MathML GSoC project was intended to improve this during the summer but has not been successful. |
| Documentation | Inform MathML users and developers. | We continue to improve our MathML documentation. With the release of Kuma and the work of Jean-Yves Perrier and Florian Scholz on MathML embedding, I hope we could eventually migrate the old demo pages to MDN soon. |
Comments
Of course, Internet Explorer gets excellent MathML support from my company's free MathPlayer plugin. In fact, it handles MathML better than Mozilla in a number of ways. Strange you would omit this considering I sign your paychecks.
@Paul Topping: Is MathPlayer development still alive? From the website I get that there is an old preview version for the next-to-latest version and that's about it. :(
Also I am not sure whether MathPlayer could even run in IE10 in Metro mode, much less on Windows RT.
MathPlayer is most definitely still alive. The latest version available is a preview release of MathPlayer 3.0. I agree that running on Metro and other devices is a problem. This is mostly a matter of Microsoft waking up someday and realizing they are going to have to deal with MathML as it is required for HTML5. Their "no plugins under Metro" philosophy is applied incorrectly to MathPlayer. They say it is for better standards compliance and pages that rely on plugins are non-standard. However, MathML in HTML5 is standard. The fact that MathPlayer has to add a plugin declaration to the page is because IE requires it, not be because the page author wants to use a non-standard plugin.
Of course, that doesn't mean that Microsoft's eventual MathML solution will involve MathPlayer. Perhaps they will use MathJax.
MathPlayer is also very much alive as a math-to-speech and braille engine that works with the screen readers used by people with disabilities. I assume they will complain to Microsoft when MathPlayer doesn't work in IE10 Metro.
BTW, MathPlayer's rendering engine is also used in other Design Science projects.
Doing whatever's needed to get MathJax using native MathML in Firefox by default again seems highest priority to me.
Perhaps it sounds like trying to breathe life into a dead horse but the way MathPlayer is implemented it really is part of the browser layout engine. The fact that its executable code must be installed separately and that IE needs some help in finding that code is does not weaken that argument.
@Paul: I'm glad that we removed misunderstandings in our private discussion and I apologize if you feel that my omission of MathPlayer was unfair. Enumerating all the MathML layout engines was not at all the point of my post as I said above. But since you mention whether MathPlayer could be compared to a native browser implementation, I think you already gave some issues above (need for a separate installation, imcompatibily with new versions, security concerns of browser vendors). This is typically the same situation we have with e.g. flash plugins and this motivated native video support. My experience with MathJax shows that there are other issues in the MathML case e.g. integration of the equation to the surrounding paragraph, dynamic updates of the formulas, CSS styling. In the case of MathJax, Davide has a done a pretty good work for the first issue but we have, I think, less success with the two others (we have to teach the users different ways than those they are familiar with). I'm not sure for MathPlayer, but the analysis of LaTeXToMathML tests mentioned in my post indicates that the most serious issue with the code generated by MathJax is that the style attribute is ignored. So I guess that would be the same for general CSS styling methods. Note that I can do the same reproach to Firefox's third party tools. For example the MathML-fonts add-on that I developed basically attaches a stylesheet to each page and this stylesheet causes the loading of Web fonts: obviously this sounds less efficient than direct installation of fonts on the system. Similarly, David Carlisle's XSLT stylesheet to support e.g. content MathML may have issues with dynamic updates and styling. So in general, my preference is for native support when it exists but otherwise third party tools are fine to address the browser's limitations and may even be at the leading edge as it is the case for accessibility support in MathPlayer.
@Robert: I agree, that's why the four first areas of my roadmap are exactly those that have been used by the MathJax team to take the decision to disable Firefox's native MathML. I think we have recently done a good job regarding the font support (especially Web fonts and MathJax font support) but some developments remain to be done on the MathJax side to make this work. Regarding spacing, I think Quentin could add support for mtable@rowspacing/columnspacing reasonably soon. As I indicated on the bug, adding two columns during the construction of MathML tables in nsCSSFrameConstructor should allow to implement mlabeledtr more or less easily. I believe MathJax uses mlabeledtr to work with accessibility tools like MathPlayer but some workaround for Firefox can still be done on the MathJax side. Linebreaking and negative spaces seem to require more knowledge of Gecko's layout model than I currently have and implementing linebreaking is certainly more work, so I'm not sure whether that can be done soon by the volunteer contributors. These features also look hard to workaround on the MathJax side.
MoCo could also become a MathJax sponsor to help the MathJax team to work on the missing features and finally make MathJax enable Firefox's native MathML by default. Note that even if it is enabled again, Web authors and users can still change the rendering mode, so working on the key features I mention above remains important.
Actually, independent of whether we want to enable Firefox's native MathML again, I think the MathJax project is typically the kind of innovative Web project that Moco would like to fund. The MathJax team has already brought several contributions to the Mozilla MathML project like MathJax fonts and is even thinking about providing a Web font CDN to Web page authors. The MathJax testsuite has hundreds of MathML reftests that could be integrated, more or less easily to the Gecko's reftests. Finally, MathJax has an enthusiastic user community which could test Mozilla MathML support in concrete applications and report bugs or other feedback.
I agree that it would be better if MathML were supported in IE without any extras that need to be installed. However, let me remind you that Firefox also requires fonts to be installed (except on recent Mac OSs), or be provided by a website, in order to produce good results, right? I bet when Firefox's MathML supported is measured against the MathML test suite, it is with STIX fonts installed. MathJax has a similar issue that every website author has to inject it into their website to get it to work. Unfortunately for the community, the MathML support situation is not as simple as we might hope. Sure, it is possible to use a definition of "native" that leaves MathPlayer out but I don't think it serves your readers well to do so.
As I already said privately, I didn't refer to my signing of your paycheck to indicate that I expected you to say things a certain way. Just that it would be improbable for you to not know about MathPlayer therefore its omission has to have some other cause.
MathML renderers in browsers have a dilemma with respect to CSS styling and style attributes. Very often MathML in the HTML page includes styling from some original document context that is inappropriate for the web page. On top of that, each browser maintains its own algorithms for choosing default fonts and sizes. Finally, the user can use browser options such as font size that affect the page formatting. The MathML renderer can try to be faithful to the styling but often it can do a better job by ignoring it.
I believe that MathML was designed to follow the XML (XHTML) philosophy where it was imagined that each MathML markup instance would be written carefully and styled (and restyled) for each context in which it was placed. This is somewhat naive and impractical. People are bound to move MathML instances around without adapting them to each context. Even if they did, it would not produce good results because the browser context can change dynamically.