**Writing Math.**

When it comes to authoring math, some simple expressions can be handled with the use of special characters, superscripts and subscripts; but more complex expressions require some hand-holding.

Today’s word processors support insertion of formulas into a document. The process most often involves the use of equation editors that guide the writer through a sequence to construct the correct terms and operators to be placed on a page.

In the case of documents being edited with OpenOffice, writers *Insert*→*Object*→*Formula *to launch an equation editor.

While at first intimidating, the equation editor is actually rather simple to use. One row of characters define a basic context for an operation, while the lower pane provides specifics of the operation or relationship. The user can then replace placeholders with specific variables to complete an equation that is then pasted into the word processor document.

These types of equations work well when building documents opened by the same word processor or when exporting to PDF files, but what happens to this math when it is displayed in a web page?

**Show Me.**

We start with a note about how math equations used to be displayed in browsers.

Up until recently, publishing work-flows that required use of mathematics used specialized typesetting commands and processors (e.g. LaTex) supported by dedicated rendering plug-ins. Other techniques rely on utilities to build image representations of the formula – these images could be displayed on most all versions of browsers and operating systems. (Even current word-processors often generate uncompressed images used as ‘stand-ins’ to show math in documents). But dedicated typesetting commands can be difficult to master, and large numbers of embedded images can add the the heft of the document size. Images also scale poorly if the user wishes to see larger representations of the equation.

More recently, word processors allow the user to export the document in XHTML format – the prerequisite step needed to use more recent rendering services available with current browsers.

When exporting a document from a word processor into XHTML format, the resulting page will often include tags that don’t look like your typical HTML.

Those tags are elements belonging to the MathML namespace, an XML representation for describing mathematical notations on the web. When a file is saved in XHTML format, browsers are clued in to the fact that the document may include elements that go beyond the basic HTML elements (like <span> and <div>), and includes elements that need special handling (like <mrow> and <mfrac>).

The problem is, not all browsers open MathML with equal skill.

Opening a MathML / XHTML file on your local machine with Firefox and Opera works relatively well – the web page looks pretty much like the same document as viewed in the word processor. Opening the same file with Internet Explorer requires a plug-in, special software from companies like Design Science that helps the browser render the math elements. Opening the same file with Chrome and Safari on different operating systems provides very uneven results.

(The only way to really see how your browser handles MathML is to access the pages at the MathML test suite.)

The problem gets more complicated when placing the same file on a web server. The server (e.g. Apache, IIS, LIGHTTPD, must be configured to serve the math-containing file as **application/xhtml+xml** mime-type – but Internet Explorer users will have to wait for version 9 before their browsers properly process such files. (IE 8 - users need to be supported by techniques that make novice web administrators cringe.)

The range of performance relates to a variety of technical issues that are beyond the scope of this note. But suffice it so say that to some web browser providers, the use of mathematics on the web represents too small a need to justify the engineering effort required to provide the depth of technologies needed for a robust implementation.

One approach to work-around the current browser inconsistencies is to a technique similar to MathJax (another Design Science supported project).

The MathJax approach is useful to content publishers who have the ability to embed JavasScript references in the pages served to the web browser. MathJax enhanced publishers include code that allows a library of MathJax functions to convert the MathML on a document into ‘normal’ HTML on the page. The MathJax library effectively replaces the browser’s rendering to present math elements on the page. This is a 'JavaScript-assisted' solution that results in consistently high-quality math rendering on a variety of browser engines.

** What's the Moral of the Story?**

As frustrating as math publishing may be, the fact is that MathML is part of the new HTML5 specification – and ALL browsers will eventually support HTML5 and MathML. So use of MathML as the standard format for math expression is not so much a matter of when, but how soon and how good.

The fact is that there are enough technologies in place now to develop more useful web applications that include formulas and equations – the state of the industry is imperfect, but for most, there isn’t time for perfect.

And only by pushing the envelope in terms of expecting more from browser manufacturers and third party providers will the efforts of technical publishers ever start to make ‘perfect’ appear a bit closer.