Call for Papers

General Information

Registration

Accommodations

Travel

Tutorials

Presentations

Schedule

Abstract

Most tools for rendering MathML [MML] can be classified into two categories: full Web browsing applications, such as Amaya and Mozilla, or plug-ins or extensions, such as the WebEQ applet, IBM techexplorer, MathPlayer (usually in the form of Java applets or ActiveX controls).

In the first case, the MathML formatting engine is implemented as part of a more general layout engine used for HTML display, which permits MathML fragments to integrate seamlessly within HTML markup [HTML]. In the second case, an external component is embedded into a larger browsing application by means of an application-specific extension mechanism. In this case the MathML formatting engine is usually completely separate from the general layout engine and MathML fragments are usually rendered inside rectangular portions of the rendering area.

This paper defines the rendering capabilities and evolution of the architecture of a standalone formatting engine for MathML that does not fit any of the categories formerly introduced.

One Markup, Different Users

When the HELM project [HELM] started, support for MathML in Web browsers was insubstantial. This resulted in the development of a new MathML rendering engine as a widget for GTK [GTK]. We were searching for innovative interactive capabilities, such as a structure-aware form of selection and the possibility to conceal and disclose parts of the displayed document to change the level of detail. The last issue is important in the context of HELM because of the verbosity of mathematical objects stored in the library.

Figure 1: A theorem from the HELM library encoded in MathML, as rendered by our tool.

Fig. 1 illustrates a screen-shot of the tool rendering a mathematical document from the HELM library, in its contracted (l.h.s.) and expanded (r.h.s.) forms. While the actual understanding of the document is outside the scope of this paper (see [HELM-MML] for a more detailed discussion), it is worth noting that this feature was implemented by means of standard MathML only (``toggle'' mode of the maction element).

Another notable feature of the widget is the selection mechanism, which allows to select whole subtrees of the MathML document. While being extremely simple to implement, this technique can be used to ease the reading of a complex mathematical formula, whether it is intended in a ``classical'' form or as an object in the HELM setting (see r.h.s. of Fig. 1). It also enables the cut and paste of MathML subtrees in a straightforward way.

Rendering to PostScript

Originally, the formatting engine was intended to be used inside GTK applications only. However, a large part of it has been designed with portability issues in mind, resulting in a rendering engine that can use Type1 fonts (and, in particular, TeX fonts) to generate encapsulated PostScript files from MathML documents. The tool has been adopted by the John Wiley & Sons, Inc. publisher for the publication of scientific articles in a InterScience Encyclopedia (Encyclopedia of Polymer Science and Technology).

The articles are encoded in a proprietary XML application, and embedded mathematical formulas are encoded in HTML or MathML, according to their complexity. The publisher adopted our standalone formatting engine to render every MathML fragment to encapsulated PostScript, each PostScript file was then converted to a GIF image, to be eventually referenced from the final HTML document. Fig. 2 shows a screen-shot of the encyclopedia where all the displayed mathematics has been rendered with the tool (the symbols appear shaded because of anti-aliasing).

Figure 2: Screen-shot from A.N.Gent, G.R.Hamed, ``Adhesion'', Encyclopedia of Polymer Science and Technology, Copyright 2002 by John Wiley & Sons, Inc.

Pocket-Size Devices

Current research on the standalone rendering engine aims at the creation of a light-weight application for handwriting mathematics in pocket-size devices, such as the Pocket PC. This will enable mathematics to be entered in a natural way using a stylus and a touch screen on devices without a keyboard. The handwriting recognition software and the rendering engine interact closely during the recognition process, as the MathML DOM tree corresponding to the entered formula is modified and refined according to user input. DOM events [DOM Events] are used to notify changes to the tree structure and content, thus providing the rendering engine with an abstract and standard notion of editing process.

This application could provide a user-friendly front-end for a number of mathematical applications which can become appealing to be executed in pocket-size devices in the near future, and MathML would be the communication protocol between the user interface and the proper application.

Architecture

The rendering context and the user expectations are very different in each scenario. There also cases where they are in conflict with each other. In the first case, we have a static document (no editing), but we have interactivity. In the second case, there is obviously no interactivity at all (PostScript is inert), but the highest rendering quality is expected. In the last case, we work in an environment that usually offers very poor rendering capabilities, but editing must be supported. How is it possible to design the architecture of the rendering engine in such a way as to accommodate all these different needs and requirements?

Multi-platform applications like AbiWords or Mozilla are usually designed in two layers: the lowest layer is responsible for storing the document in some rendering independent fashion. A second layer, on top of the first one, implements a ``view'' for the underlying information. The ``view'' is based on some abstract C++ classes representing fonts, the system-dependent font selection mechanism and the rendering device which provides very simple primitives for drawing text and lines on the output device. By instantiating different implementations for those abstract classes it is possible to use the same rendering engine with different kinds of fonts, windowing frameworks, or operating systems.

Our rendering engine has a similar layered architecture. The lower level is naturally provided by some DOM implementation [DOM], since MathML is an XML application. The rendering level was initially designed as described above: in the GTK context, the rendering device class was such that the invoked drawing primitives were forwarded to the GTK layer and then, ultimately, to the graphic hardware. In the PostScript context the device was generating PostScript commands corresponding to the invoked drawing primitives.

Even though this layered architecture is well established, as testified by the number of applications adopting it, in our context it has some important drawbacks: first, the classes implementing the rendering layer accumulate many rendering-related pieces of information that can be useful in some contexts, but not in all of them. As an example, when rendering to PostScript it is not necessary to keep track of the selected state of a given MathML element, since no selection is possible at all. Second, quality of rendering requires a precise knowledge of the fonts used and their characteristics. Evidence of this fact can be found in the appendix G of the TeXbook [TeXbook], where the algorithm for typesetting mathematical formulas is described in detail: several font specific parameters are taken into account, and the algorithm itself relies on many capabilities of those fonts, which were specifically designed to be used with TeX [MF]. Thus, an approach based on the abstraction of fonts does not fit well when quality is a major issue. Lastly, there may be cases where precision and completeness can be relegated in favour of a cheaper implementation, in terms of CPU and memory usage. This is a common trade-off on systems with limited resources, like pocket-size devices. An approach solely based on the rendering device abstraction does not have enough flexibility.

The solution we adopted in a more advanced prototype implementation was partly inspired by the area model in the XSL recommendation [FO]. The basic idea is to add a further layer which represents in a possibly device-dependent way the result of the rendering process. This layer is made of areas representing the final layout and the properties of the rendered formula. The source MathML document is thus compiled into a document of areas through the rendering classes of the middle layer. Since areas are instantiated by the rendering device, they can accommodate the properties of concern of a particular environment.

The rendering device too was redesigned to have a higher-level interface. Consequently it has been renamed to ``Math-rendering device''. Primitive operations on this device reflect context-sensitive mathematical layout schemata. For instance, instead of primitives for drawing text and lines, there is a primitive to stack two sub-formulas in order to form a fraction. Similar primitives are provided for everything which could benefit from (or require) a deep knowledge of the rendering environment. As it was done before for the rendering device, the Math-Rendering device can be instantiated to different implementations, allowing precision and quality, or alternatively light-weight rendering, depending on the actual context (e.g. availability of TeX fonts). The remarkable fact is that the context-dependent aspects of the formatting process have been moved away from the layout classes. The layout classes altogether can be regarded now as an abstract, device independent implementation for typesetting mathematical formulas encoded in MathML.

Concluding Remarks

Through progressive refinement, our architecture proved to be successful since it was ported to several different environments achieving most of the issues of concern in each environment. Development is still under way in order to stabilize the tool and improve rendering quality, so to exploit the full potential of Type1/TeX fonts.

Although all the examples in this paper illustrate how MathML markup plays an important role per se, we understand that the possibility of embedding our rendering engine in larger browsing applications and processors for formatting is a major concern. In a broader view, the development of standalone engines aims at a more modular, component-oriented design of applications. There are two aspects that need to be addressed: the first one is the need of a more standardized way to embed standalone components inside hosting applications. The recent note from the W3C about Component Extension should be considered as an interesting starting point. The second aspect is that the embedding should not compromise quality and capabilities of the rendered document, which is often the case using today's components. To this respect we believe that the adoption of an area model is a first step that can help this process.

At this point it would be interesting to integrate the rendering engine with a Formatting Objects processor. This would allow us to test the possibilities of our approach, possibly resulting in a quality formatter for documents with mathematics. It would represent an alternative to TeX solely based on XML technologies, with all the advantages that XML brings along today.

Bibliography

1. ``Mathematical Markup Language (MathML)'', Version 2.0, W3C Recommendation, February 21, 2001, http://www.w3.org/TR/MathML2/
2. ``HTML 4.01 Specification'', W3C Recommendation, December 24, 1999, http://www.w3.org/TR/html4/
3. ``Document Object Model (DOM) Level 2 Core Specification'', Version 1.0, W3C Recommendation, November 13, 2000, http://www.w3.org/TR/DOM-Level-2-Core/
4. ``Document Object Model (DOM) Level 2 Events Specification'', Version 1.0, W3C Recommendation, November 13, 2000, http://www.w3.org/TR/DOM-Level-2-Events/
5. ``Extensible Stylesheet Language (XSL)'', Version 1.0, W3C Recommendation, October 15, 2001, http://www.w3.org/TR/xsl/
6. D.E.Knuth, ``The TeXbook'', Addison-Wesley, Reading, MA, USA, 1998.
7. D.E.Knuth, ``The METAFONT book'' Addison-Wesley, Reading, MA, USA, 1994.
8. ``An Hypertextual Electronic Library of Mathematics'', http://www.cs.unibo.it/helm/
9. A.Asperti et. al., ``Formal Mathematics in MathML'', Session Presentation at the first MathML International Conference, University of Illinois, Urbana-Champaign, Illinois, USA, October 2000.
10. ``The Gimp Tookit'', http://www.gtk.org