Mozilla MathML Project: status report
By fredw on Saturday, August 27 2011, 15:40 - Permalink
More than half a year has passed since my last status report on the MathML project and so I think it is time to provide the latest updates. A lot of pending bugs that I mentioned in previous reports has been fixed. A noticeable exception being support for Arabic mathematics, since people who showed interest on this work could not finally make it. Because Mozilla uses a rapid release process now, the description in this post covers four different versions of Gecko that I indicate in parentheses.
The most exciting thing has been to see contributors getting involved or continuing to work on the MathML project. I would like to thank Bill Gianopoulos for finishing the work on MathML linking and regularly testing all the MathML patches as well as Florian Scholz for starting to work on Gecko and continuing to write MathML documentation. Obviously, I'm also particularly grateful to my intern Jonathan Hage, who has definitely been helpful this summer. I've appreciated the assistance of all the other developers, reviewers, bug reporters and documentation authors and I hope that participation will continue to grow!
Below is a summary of the work accomplished since Firefox 4. I also expect to update the planning for MathML.
- Stretching of Operators and Mathematical operators
- Embellished operators are now entirely supported. (Gecko 5.0)
- The MathML Operator Dictionary has been upgraded to the version proposed in the MathML 3 REC. (Gecko 5.0)
- The set of XML entity definitions for characters - including many mathematical operators - has been upgraded to follow the corresponding W3C recommendation (Gecko 5.0). I've reported this bug to several other browser authors and hope they will align on this set of definitions. Anyway, for compatibility reasons, I recommend Web authors to directly Unicode characters or their numeric entity references.
- The Asana-Math
font is now usable for stretching mathematical operator (Gecko 7.0)
To test it, you may want to modify the
font.mathfont-familyentry inabout:config.
It would really be interesting to support more mathematical Open Type fonts. If you want to help us, have a look to the preliminary bug to work on (a student wanted to work on this bug as a summer project but was not able to do so...).
- Linking
One of the most essential feature of the Web is back in the MathML world! There is still some undergoing work to improve rendering/UI but you can now use links in mathematical formula. Support for the old XLink syntax has been restored but it is recommended to use the new MathML 3 href, that avoids the use of XML namespaces.
- MathML elements/attributes
The implementation of
mstylehas been fixed (Gecko 6.0). In particular, themathvariantattribute on a<mstyle/>now applies correctly to its<mi/>descendants.The <math/>element should now be usable as an mstyle (Gecko 8.0). Names for negatives spaces are recognized (Gecko 7.0). There are many other improvements for<mfrac/>,<mfenced/>,<mpadded/>,<mtable/>and<munderover/>including new MathML 3 attributes. As usual, you can read the current status on the MathML project page. - MathML Documentation
The MDN documentation has been expanded and updates have been made to indicate fixes or support for new features. Old MathML demo pages are still being updated and prepared for migration to MDN.
Comments
Very cool.
The mathvariant inheritance bug required some ugly CSS workarounds.
And the resurrection of the href attribute is long-overdue.
But I'm curious whether you have any thoughts about where else MathML authors (in particular, users of itex2MML) can now go, that they couldn't before.
Working on a project that requires elementry math. Will be very happy when I can display long division in Firefox without having to use an image.
Thanks for your hard work,
John
"This element may be useful to improve the rendering of formulas (for example, MathJax uses it). There are many new features that could be interesting to implement..."
That's exactly the sort of thing I'd like to hear.
Currently, itex2MML uses only mpadded@width and mpadded@lspace (the intersection of the set of things that I needed and the set of things that were implemented at the time).
It would be nice to see what else can be done, now. Since, I gather, you're using itex2MML in some of your own projects, it seems that you have a vested interest in this, too.
Well, I don't think using an image is mandatory, you can probably achieve the same results with the help of CSS (see the MathML for CSS Profile) or with mtable and menclose@notation=longdiv as described in the MathML2 spec:
http://www.w3.org/TR/MathML2/chapter3.html#id.3.3.9.3
(I haven't tested it, though). Of course the new MathML elements for elementary math are more convenient and powerful and it would be great to implement them in Firefox. The bug entry is (any volunteer?):
https://bugzilla.mozilla.org/show_bug.cgi?id=534967
@Jacques:
The changes are in Firefox 7 (currently in beta). Be aware that the behavior of lspace has changed and no longer increases the width of the mpadded element. I don't know if that can help, but I've done a quick search below to see where mpadded@voffset in used in the MathJax test suite (you can see the source of the page to get the LaTeX input). Davide (the main MathJax developer) can provide you more use cases if you ask on the MathJax mailing list.
LaTeXToMathML/roots/root-3.html
LaTeXToMathML/LaTeX-1.html
LaTeXToMathML/arrows/arrows-3.html
LaTeXToMathML/layout/lower-1.html
LaTeXToMathML/layout/raise-1.html
I don't think the change in mpadded@lspace will affect my current usage, which is explained here:
http://golem.ph.utexas.edu/~distler...
I had to update the Instiki (&Heterotic Beast & mars) sanitizer(s) to accept mpadded@voffset.
Testing it out in Firefox 7, I'm a little confused by the behaviour.
It seems to me that
<mpadded voffset="v" height="h" depth="d">...</mpadded>
should bepretty much like the LaTeX command
raisebox{v}[h][d]{...}
(taking account of math-mode, of course). Indeed, if you supply both the @height and @depth attributes, that seems to be the case. But, according to
http://www.w3.org/TR/MathML3/chapte...
if those attributes are omitted, the default values should be those of the actual content (which, not coincidentally, is what the LaTeX command does).
But the actual behaviour that I seem to be seeing in Firefox is that it seems to treat the default values as zero. Am I interpreting what I am seeing correctly? If so, then you have a bug ...
"Hence, we have only kept the way it was implemented, fixed the error and added support for voffset."
OK, well let me sharpen my question. What I am trying to do is implement the MathML equivalent of the LaTeX
\\raisebox{voffset}[height][depth]{content}
command. It turns out that the interpretation of mpadded@voffset is the same as the LaTeX one. But (as you can see from the screenshots I sent you), the interpretations of @height and @depth are different.
Given values for height and depth in the LaTeX command, what values of mpadded@height and mpadded@depth should I supply to reproduce the LaTeX behaviour?
"I think mpadded should really apply to the logical box, a separate bug can be opened for that... "
That would make a whole lot more sense. It's not the LaTeX behaviour (which would be hard to reproduce precisely), but it would seem to accord much better to what the MathML Spec says