After yet another feedback about the fact that Mozilla's MathML rendering is ugly without appropriate fonts installed, more progress has be made towards our font improvement plan. In this post I will talk about what is going on, even if that is still work-in-progress. I will hopefully have the occasion to describe the evolution in my next status report for Gecko 13, 14 and 15. I will also mention other activities in the MathML project.

### The Big Picture

First it may be worth to recall again why appropriate fonts are necessary to render mathematical expressions correctly. One of the most obvious reason is that there are exotic mathematical symbols not contained in mainstream fonts. The style of the font, its spacing etc are also more subtle aspects (that may depend on tastes or habits) making people feel that a formula is "good-looking".

More importantly, some symbols (e.g. sums or integrals) should be displayed larger in some situations while others (e.g. braces or roots) have to stretch to cover subexpressions. For that purpose, one needs fonts with size variants as well as glyphs to build characters by parts.

Since Firefox 3.6, the Mozilla MathML team has made several efforts to improve the font support. The table below compares the rendering of a Nightly build (with work-in-progress patches) against the default rendering of Firefox 3.6.

### The Default Rendering

Let's first consider the default rendering. Note that some generic Unicode code points exist to stretch characters and are used if possible. Hence, this rendering may be worse or better than the one shown above, depending on which fonts are available on the system.

Additionally since bug 414277 is fixed, a scale transform may also be applied to stretch a character if it is not possible to construct it from the fonts available (compare the current default version with the one of Firefox 3.6). Note that for some less often used operators (e.g. quadruple arrow) this latter technique is the only way to stretch them because no mathematical fonts provide the necessary glyphs.

Although the default rendering is acceptable in some situations like elementary math, specific fonts are indispensable to obtain a decent rendering with more advanced notations. There are essentially two directions possible: support more fonts and/or ensure recommended fonts are available. That is the subject of the two next sections.

### Generic Support for Open Type fonts

The first direction is to support as much fonts as possible, to increase the chance to find one that can be used. Many mathematical fonts are installed by default on most operating systems, like Cambria Math or Symbol. These fonts allow to display the most common mathematical symbols and to use Unicode constructions to stretch operators.

To obtain complete support of a given font, we currently use our own tables to describe the size variants and constructions. However, we have to write these tables for each font and so this method does not provide a generic way to support mathematical fonts. MathJax fonts will be supported in Firefox 13 and become the default. For the moment, STIX fonts are completely supported since Firefox 3.7 and Asana font is supported since Firefox 7.

Many new Open Type mathematical fonts have recently appeared, but there are technical limitations that prevent us to use our current approach. The big advantage of these recent fonts is that they contain a table describing the size variants and constructions. Hence a worthwhile work could be to refactor our code for stretchy operators and to be able to directly read the tables from the font files. The corresponding Bugzilla entries are bug 663740 and bug 407059. That would give us a generic support for all Open Type mathematical fonts that have the relevant table. This is also interesting to provide more font styles to the users. Here is a list of the Open Type mathematical fonts I am aware of:

• Cambria Math
• Neo Euler
• STIX 1.1
• Latin Modern Math
• Lucida fonts
• Asana Math

Additionally, these fonts actually contain a wealth of information allowing accurate positioning and spacing for the mathematical formulas. In the future we could use the Open Type Math table instead of our heuristic rules inspired from TeX. That could greatly improve the rendering of the formulas.

### Ensuring Availability of Recommended Fonts

The second direction is to ensure that recommended fonts are available. Indeed, the main fonts on which we rely are generally not installed by default on the operating systems. Moreover, the installation procedure may not be convenient for all users and there are even some platforms like mobile devices where it is difficult to install new fonts.

We are working to make Web fonts usable to stretch MathML operators. When this bug is fixed, it will be possible either to ship some fonts inside the browser (as Webkit folks do) or available from a public server (as MathJax folks do). However, size and licence may be a problem for the former option. As for the latter, MathJax experience shows that mathematical fonts are generally too big to make this efficient (download time, caching etc), especially on mobile devices.

Another option is to make the installation easier. The MathML-fonts add-on has been written for that purpose. The users will just have to install these mathematical fonts like any other restartless Firefox add-on. The add-on essentially attaches a stylesheet to each page visited. This stylesheet contains @font-face rules to load the mathematical fonts contained in the add-on. Again, the work is not finished yet: because of the bug mentioned above, these rules do not work for stretchy MathML operators yet. Moreover, whatever the technique used, it seems impossible to register the stylesheet with e10s Fennec. That is annoying, since as said above this add-on is particularly important for mobile devices. I expect the first issue to be fixed in Firefox 15 but the second one is a bit out of the scope of the Mozilla MathML team...

The plan is then to display an information bar suggesting to install the add-on when a page containing MathML is visited. Actually, this message will only appear when we detect a stretch failure for MathML operators. Once this bug fixed, that will end a series of regular reports that started more than 10 years ago!