MathML in Mozilla

Maintained by Roger B. Sidje <rbs@maths.uq.edu.au>

The text below is dated May 1999 when the project started. Since then some milestones have been achieved, and while an elegant MathML renderer remains the primary focus, new tools have come to being. For example, live TeX-to-MathML translations are possible with server-side convertors such as itex2MML and the prototype JavaScripted MathML editor makes not as outlandish as it may have seemed at the time. Moreover, other interoperable approaches such as XSLT and SOAP have been developed as well.

The Big Picture

Both the output and input of MathML will be investigated in this project.

• The priority of the project will be to provide a compact and fast engine that will process MathML and enable Gecko to render mathematical expressions $...$ in graphical form.

• Another goal is to provide a WYSIWYG interface to MathML. This will be a graphical equation editor with an internal representation in standard MathML text. It will therefore provide a basis for:

  • an equation editor button on Composer;

  • the support of an input field

• Transformation Services are also of interest. The lingua franca for formula-intensive documents is TeX/LaTeX and the use of MathML is not yet widespread. Hence it would be useful to have a TeX-to-MathML equation converter. There are other notations for which converters to MathML can be useful. In order to keep the core MathML engine compact and fast, no format other than MathML will be supported. It is envisaged that proper modular design principles will be adopted so that interested parties can contribute separate converters which can be chained to the core MathML engine. This will provide a better alternative to cumbersome inline GIFs and Java applets that are often used to represent equations.

Implementation

A mathematical expression can be represented as an aggregate set of boxes. These are the bounding boxes that would enclose mathematical entities (literal symbol, operator, delimiter, etc). With rules governing the positioning of these entities (subscript, superscript, fraction, etc), it is possible to construct the box-model in a recursive manner by traversing the parsing tree of the expression.

With the object-oriented paradigm, each box can be viewed as an object that has its own specific properties and shares a common set of properties with other objects. With the CSS paradigm, each box can be viewed as a CSS frame that possibly embeds other CSS frames. Hence there is a direct correspondence between the two paradigms.

MathML offers two formats for representing an equation: presentational tags and semantic/content tags. Given an equation in either format, the MathML project will ultimately aim at constructing a lump of CSS frames that can then be passed onto Gecko for layout and display.

The graphical input component of the project will seek to provide a point-and-click authoring tool for creating and editing mathematical expressions. But beneath the graphical outward appearance, there will be plain MathML text that could therefore go in Composer or in the input field of a form.

What about style sheets, JavaScripting, cut'n paste and the likes? As you see, in addition to getting the foundation right, there are many open issues to the project awaiting your input and help!