Web publishing of mathematical documents is a serious challenge and has been discussed in several documents [1,2,3]. Recently the MathML standard has been published as a W3C recommendation [3,4]. Popular browsers such as Netscape Navigator and Internet Explorer do not (yet) support it although some developmental plugins are available. Since the acceptance of any standard is dependent on the ready availability of high-quality software that implements it, and since two developmental browsers with built-in MathML support are now available, it seems vital to evaluate these tools critically to see if they are suitable vehicles by which the standard will establish itself.
I tested the MathML browsers using output from a new unreleased version of the TeX to HTML translator TtH. This version, called TtHMML, translates LaTeX and TeX files including mathematics to HTML with equations embedded in as MathML presentation format within <math> ... </math> tags. This is the format that both Amaya and e-Lite recognize3. TtHMML is itself still experimental but it solves the problem of generating significant MathML equations of a variety of types without resorting to hand coding of MathML, which is extremely verbose. The platform used was a 180MHz Pentium Pro with 64 MB of memory, running Linux 2.0.29.
As a baseline for comparison. The same documents were translated by TtH into HTML4.0 in its usual fashion, and browsed using Netscape Communicator 4.04. In case there be any suspicion of hidden bias, let me declare my personal interest as the author of TtH. Naturally these are personal opinions, your mileage may differ.
A practical test was done by providing the browsers with a variety of real mathematical documents. Figure 1 illustrates a simple equation with vectors and tensors rendered by Netscape from HTML (a), Amaya from MathML (b), and e-Lite from MathML (c).
No notice should be taken of the horizontal positioning of these
captured bitmaps, or of the fact that the Amaya browser used a
different background color. However, some important considerations are
immediately apparent. Amaya has a serious shortcoming in that it does
not render bold characters (e.g. the vector E) as bold. Instead
it reports on the command terminal for example: ``line 65,
char 25: Unknown XML attribute fontweight''. This is only one of the
attributes Amaya does not render. In fact Amaya recognizes hardly any
attributes, which constitutes a very serious limitation. For example
without the ``linethickness'' attribute of <mfrac> one can't
render properly \atop (a fraction with no line). Its exponents
are uncomfortably high, but that is more of an aesthetic critique than
a critical point of semantics. e-Lite renders bold characters
correctly, but appears to require upright to be explicitly specified as well
as bold to behave in standard TeX fashion, which TtHMML does not yet
do. e-Lite has different aesthetic problems in that the symbols
in exponents are uncomfortably small and the parenthesis at the end of
the exponent ``crashes'' in to the next symbol (dt). More ugly is that
e-Lite does not recognize the entity   which is used to
space the equation label from the equation. Semantic difficulty is
possibly implied by the excessively large parentheses on
Es(ws), and is definitely induced by the fact that
\leftrightarrow (⇆) is not recognized over the
capital Pi indicating a tensor. Netscape renders the equation in TtH
HTML encoding quite successfully. Here is the same equation rendered
by your browser:
A paragraph with a longer equation shows other features as illustrated in figure 2.
The most dramatic difference here is that e-Lite does not render the display equation at all. It is not clear why, but the equation is quite long and I assume it overflowed some limitation in the parser. e-Lite rendering of the brief in-line equations is very poor because they float high above the line. The hats on the s and i vectors are omitted. Amaya succeeds quite well with the equation. Its in-line equations are well aligned with the text and it includes the hats but needs a great deal of space to do so in-line. Its spacing in the equation is poor in places, for example for f. The Netscape rendering is quite readable but it has excessive space for the fraction with ``hatted'' symbols in the numerator, and the hats cannot be rendered in-line, so they are indicated in a way that is not pretty but is fairly intuitive.
Entity recognition is fairly good, although some problems have already been noted. In figure 3 is shown an example generated from:
$$ \div \diamond \cup \cap \subset \supset \approx \sim \propto \parallel \perp \pm \times \wedge \vee \oplus \otimes \sum \prod \in \equiv \leftarrow \rightarrow \Leftarrow \Rightarrow \leftrightarrow $$
Amaya misses ∥ and ∨ and runs adjacent arrows into each other. e-Lite misses diamond and wedge, as well as leftrightarrow (already noted). A difficulty all browsers are going to have with MathML is that the entity list is immense and there are numerous synonyms, so supporting the whole standard is going to be tough and there is no accepted subset choice that can be regarded as a de-facto standard. The HTML code renders well on Netscape, although there are other entities missing from the symbol fonts (e.g. dagger, not shown) that it does badly on.
Amaya has a professional distribution. Installation is relatively painless but not fully automated. It starts quickly, in just a second or two, and comes complete with built-in extensive help files. As a routine browser Amaya is not attractive compared with the popular browsers. Rendering and window refresh are tolerably fast but rather ``flashy''. Windows occasionally get left blank or partly blank.
Amaya sets out to be more than just a browser. It is an editor too, even of mathematics. This impressive achievement calls for compromises on the browser interface. Link following, for example, requires a double click rather than the standard single click. Amaya lacks many of the refinements that make the dominant browsers more user friendly, for example the reporting of a link's address when the pointer is over it, is something I miss. It doesn't display file directories so you can't browse local file structures with it. If MathML were a major part of your web activities and Amaya had full rendering capability, then you might consider using Amaya routinely, otherwise not.
The e-Lite distribution is obtained via the net from IceSoft's site in Norway. There is an automatic system detecting applet on the download site which gave a Java warning from my browser and was confusing about what was required so I just manually downloaded the install package. The connection I was able to get was extremely slow. Downloading 3.2 MB over a roughly 3 kbaud average connection takes a long time. I upgraded my Java environment prior to downloading e-Lite because it needed Java 1.1. That was a nuisance, but I guess it may help me in future. Once I had things set up, the installation which is all automated was straightforward. An option is offered to include the configuration with WebEQ integrated in to provide MathML support. I naturally chose that. Then I had to get the one week trial license which was emailed to me in less than 30 seconds when I registered.
The program then opened up without any difficulty, taking typically ten to twenty seconds to the display of the home document, which is similar to Netscape. When it starts, e-Lite consumes about 12Mb of memory for the java runtime environment in comparison with typically 8-9Mb for Amaya and Navigator.
e-Lite has rather complete support for HTML including tables. It does not support the symbol font within HTML. It also has one or two bugs. For example, is not honored within headings. It animates multiple gif files, like Netscape, but does not recognize all the inner coding concerning timing and repetitions. For example a gif that was set up to cycle 4 times and then stop just kept going for ever. Viewing standard HTML files, its scrolling is fast enough to be just acceptable. On any platform for which Navigator is available, though, you would only choose e-Lite for special purposes like its MathML capability.
e-Lite's drain on platform resources is substantial even for standard HTML files. By the time one has viewed a roughly 50k file, the jre process is up to 18MB. More significantly e-Lite seems to consume nearly 30% of the cpu cycles even when idling. Presumably this is some continuous polling that the program is doing. When added to the X overhead that it engenders, this drain seems excessive. Netscape, resource hungry though it is, is not in the same resource hog league as e-Lite.
When it comes to MathML documents, e-Lite becomes desperately slow. It takes 1 minute to report ``parsing done'' on a 72kb HTML/MathML file with a fair number of complicated equations. During that time the browser is almost frozen. Even when completed, scrolling is substantially slowed and the memory consumption rises to 22MB for jre alone. Hitting the reload button takes just as long to parse, and pushes the size up to 25MB. Going back and then forward again to the MathML page requires that one minute all over again, consuming most of the cpu in the process. No clean-up seems to take place and the footprint goes up to 27MB. The jre footprint never seems to decrease. This makes the browser essentially unusable for browsing substantial MathML documents.
Netscape Navigator is probably well known to most readers and a review of its usability is inappropriate here. The HTML that TtH produces renders extremely fast on Netscape (or Internet Explorer for that matter) because it requires only characters and the table parsing, which in Netscape is quite fast, at any rate far faster than the MathML parsers in either of the other browsers.
Because of the somewhat unconventional font usage and the need for the symbol fonts, users on platforms other than Windows may have to make minor adjustments to their browser configuration. Under X, a line has to be added to the .Xresources file to enable the symbol fonts. On the Mac platform the encoding needs to be set to MacRoman. In all cases, the browser must, of course, be set to use document fonts. These minor adjustments are far less trouble than changing to a whole different browser or even than installing a plug-in.
e-Lite is essentially unusable for substantial mathematics documents on this moderately powerful platform under Linux. It is painfully slow and its ever-increasing resource demands eventually overwhelm the system. Even without this problem, its MathML rendering is so limited that it does not make mathematics browsing practical at all.
Amaya is a faster and more robust MathML renderer but has so many limitations even in the Presentation tags that it is unable to support serious mathematics browsing. The absence of the ability to change the font weight to bold, in equations, for example, is a debilitating fault.
Mathematics rendering within HTML4.0 requires creative use of tables for layout and the <font> tag, which is ``deprecated''. Even so, the HTML output of TtH gives far more completeness of mathematics support than either of the MathML browsers considered, and does so with aesthetic qualities that are as good or better in all but a few cases. Moreover, this approach does not require the use of a special browser, instead utilizing the built in power of the tool that users are familiar with.
MathML needs a powerful renderer to turn it from a hollow standard into a practical reality. Amaya is by far the better of the two reviewed here, but still has too many limitations for practical everyday use. Till those limitations are overcome, the approach of TtH to mathematics web publishing using HTML4.0 will remain definitely the most practical.
2See my home page for affiliations
3I did not test WebEQ in its Netscape applet
form because it uses an HTML format that requires the MathML to be
represented in a different container. I did not test IBM's
techexplorer because it does not run on linux.