## Mozilla MathML Project: overview of future improvements and other bugs to fix

By fredw on Thursday, August 12 2010, 23:00 - Permalink

In this blog post, I'm going to give an idea of undergoing work in the Mozilla MathML Project. I've also selected a list of MathML bugs that would be interesting to fix in the future. Although I'm not going to give detailed explanations, I hope it will help to see the big picture and maybe bring new contributors to the project.

First, as indicated in the planning for MathML, the two priorities are:

**Stretching of Operators and Mathematical Fonts**In mathematical formulas, we need to stretch symbols (such that braces "{" or square roots "√") or to draw large operators (such that sums "∑" or integrals "∫"). The typical way to do that is to use mathematical fonts, which provide glyphs of different sizes or that can be combined together to get a large symbol. Recent work has given a

**complete support for STIX fonts 1.0**. Another method visible in a previous blog post is to apply a scale transform to the symbol. This provides a**fallback when STIX fonts are not installed or not sufficient**(for example for some accents, triple arrows or large operators). This may even slightly improved the accuracy of the standard stretching. With these two improvements,**all the bugs reported by users for stretchy symbols will be fixed in Firefox 4.0**.In the future, it would be interesting to be able to stretch operators in the diagonal direction as well as inside mtable cells, the combination being particularly useful to draw diagonal arrows. The idea to get a "beautiful" diagonal stretching is to use the current stretching for horizontal/vertical operators, followed by a rotation. There are also two annoying bugs causing stretch failures that are worth fixing.

For the mathematical fonts,

**support for Asana-Math font is underway**. Support for Cambria Math font would also be nice, because it is installed in recent versions of Windows, Microsoft Office and other Microsoft's products. For both fonts, it is helpful to extract information from the Open MATH Table and it will even improve the rendering of formula beyond stretching. There are also**various proposals to inform user of lacking fonts and launch an automated installation**.Finally, related improvements for operator dictionary, embellished operators, operator forms and large operators are coming in a near future.

**MathML Project Documentation**For quite a long time, the Mozilla MathML Project Page had been lacking maintenance and most pages were outdated. Last April,

**we started to migrate and update the former project page to developer.mozilla.org**. The page Authoring MathML now briefly gives the principal hints to use MathML in XHTML (until we have HTML5) and then presents miscellaneous authoring tools. A more up-to-date Status Page is available and includes new features of MathML 3. Some pages to register our results of MathML3 Testsuite have been prepared but are mostly empty for the moment. Finally, for people willing to contribute to the project,**new pages for MathML development are available on wiki.mozilla.org**. In particular, one can find there more precise information on the planning for MathML.Updating MathML documentation is something for which we could get more help and the migration to wiki pages is likely to make contributions easier. However, this migration is not complete yet. Apart from remaining screenshots and old documentation on fonts, the main problem is that developer.mozilla.org does not allow the use of MathML. Hence, we need to

**wait MathML-in-HTML5 support on developer.mozilla.org to migrate demo pages**. Additionally, we need to fix several errors in the demo pages. Finally, let's mention**a seven-years-old bug for which help would be appreciated: translating the MathML start page to Arabic and Chinese**.

There are of course many other topics to work on:

- easy-to-fix bugs: see 411227, 546044, 538965, 553917, 553918, 557084, 487587.
These bugs are

**good candidates if you are a new contributor**. There are three bugs of the list above that I think are worth fixing: highlighting of selected operators, thickness of bars when printing and finally sending parsing errors to the console. - drawing of primes
The markup recommended by the MathML Working Group for expression such that "f prime" is to write the prime in a superscript i.e.

`<msup><mi>f</mi><mo>'</mo></msup>`

. Nevertheless, prime glyphs are often raised by default and hence we should not render them higher. Because of this problem, people have also used the markup`<mi>f</mi><mo>'</mo>`

instead and this case should also need to be taken into account. - linking
In the past, we were able to use XLinks in mathematical formula but unfortunately MathML nodes are no longer linkable. We must

**restore our linking support for MathML and implement the MathML 3 href attribute**. - refactoring and new features
We need to cleanup our layout code. This will be required to implement many features of MathML 2 and MathML 3. Note that

**the support for right-to-left mathematical formulas is in progress**. - mstyle
`<mstyle/>`

is similar to the`<style/>`

element of HTML in the sense that it allows styling of a MathML fragment. Nonetheless, it is a bit different because it does not always follow the standard inheritance model of CSS.**Some tests are available and demonstrate that several mstyle attributes have no effect**. I don't know if all are really used in practice, but at least users reported the important case of the mathvariant attribute. Moreover, we should allow the`<math/>`

element to support mstyle attributes. - linebreaking
This is one of the most prominent new feature of MathML3 but unfortunately also one of the weakness of our MathML support. We can

**only break at the level of the <math/> element, but no heuristic rules are implemented and we can't break deeper in the formula tree**. The desired approach would be to have a clever linebreaking at mathematical operators. Also, several issues exist for MathML inside a HTML document, because**inline MathML insertion does not behave as an inline element**. This is particularly annoying when we have punctuation marks after an inline mathematical expression.

## Comments

"for example for some accents , triple arrows or large operators" : I fdon't understand...

The standard method to stretch some characters is to use glyphs of different sizes or combinable together. STIX fonts do not provide these glyphs for all the stretchy characters, even if they have one glyph to draw most characters to their *normal size*. This is for instance the case for quadruple integral (⨌), rightwards triple arrow (⇛), and actually most stretchy characters of the MathML 3 dictionary. For these characters, we now scale the glyph of normal size.