another feedback about the fact that Mozilla's MathML rendering is ugly
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
|Default (Firefox 3.6)
|Asana, MathJax, STIX
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
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
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
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...
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