HTML Math Implementation Goals

Introduction

Rendering mathematical and other technical notation is a difficult task. Mathematical notation not only involves the use of a large extended symbol set, it relies on a rich collection of 2-dimensional layout schema, such as fractions, exponents, radicals and matrices. For these reasons, technology for scientific communication has traditionally lagged behind plain text processing tools, and in particular, the inadequacies of HTML for technical documents have limited the effectiveness of the Web for the transmission of scientific and technical material.

At the same time, the demand for effective means of electronic scientific communication is high. Increasingly researchers, scientists, engineers, educators, students and technicians find themselves working at a distance and relying on electronic communication. This extended scientific community represents a large commercial market that is not being well-served at present. Consider:

The academic research journal market is facing a financial crisis. While library budgets decline, the number of specialized research journals with fixed printing costs increases. As subscriptions decline, the burden of supporting such journals increasingly falls on fewer, larger institutions, in effect decreasing the availability of information. In spite of this substantial financial pressure for low fixed cost, easily distributed electronic journals, they have had a minimal impact to date, in large part because of the inherent inadequacy of HTML for technical documents, and because of the lack of effective authoring tools.
The commercial publishing community has an interest not only in academic journals, but also in interactive, online texts. This market also utilizes CD ROM publishing, again because of the inadequacy of HTML for scientific text, and because of the lack of a proven online business model. However, as internet commerce develops further, and the Web further permeates the home environment via Web TV, internet computers and other home oriented devices, the incentive and market for genuinely online texts will grow rapidly.
The education community continues to incorporate more and more online materials into the curriculum both in response to the changing education needs of society, and to government incentives. In spite of this, science and mathematics teachers, usually with limited time and equipment resources, are severely hampered by the difficulty of authoring technical Web documents, and their subsequent poor quality.
The corporate and academic R & D community must often spend scarce resources merely communicating technical information in a variety of formats. Results obtained in one computer algebra system are very difficult to share with colleagues using another system. Similarly, papers written in TeX are difficult to share with a colleague using Word. All too frequently, the result is inadequate communication and duplication of effort. Developers of mathematical software, in an attempt to address this problem, formed the OpenMath Consortium in 1993 "to provide a universal protocol for the exchange of mathematical data between programs." However, this effort is still primarily in the prototype stage.

Taken together, these markets represent billions of dollars of business world wide for a robust HTML Math solution. Of course, such a solution necessarily has two parts -- a mark up standard, together with an implementation. The issue of a mark up language standard for HTML Math is addressed elsewhere. In this document, we focus on possible implementation strategies for HTML Math.

Motivating Examples

HTML 3.2 does not provide an adequate solution for scientific notation. To illustrate its main weaknesses, consider the following four examples.

Basic Examples

Example 1: Consider the equation . On my system, this equation is sized to match the surrounding line at 14pt. Of course, if I change my preferences, the equation is too small or two large.
A second point to observe is that the equation image was generated against a white background. Thus, against the default gray background, the anti-aliasing is wrong. If your browser allows you to over-ride background colors, set your background to white, and compare the difference in quality.
The net effect on most platforms is that the equation is significantly harder to see, read, and comprehend than the surrounding text.
Example 2: Consider the equation . This equation has a descender which places the baseline for the equation at a point about a third of the way from the bottom of the image. One can pad the image like this , so that the centerline of the image and the baseline of the equation coincide, but this causes problems with the interline spacing, which also makes the equation difficult to read. Moreover, center alignment of images is handled in slightly different ways by different browsers, making it impossible to guarantee proper alignment on different clients.
Example 3: Print this document. The resolution of the equations will be around 70 dots per inch, which the surrounding text will probably be 300 or more dots per inch. The disparity in quality is judged to be unacceptable by most people.
Example 4: Try to cut and paste an equation into another application. This obviously fails. Moreover, cutting and pasting from the source text does little better, unless the author has included some sort of mark up in an <ALT> tag.

Intermediate Examples

Example 5: Consider again, , this time rendered with WebEQ, a Java applet. The alignment issues from the previous examples persist. However, by right clicking over the equation, the user can bring up a control panel, and adjust the equation font size to match that of the ambient text. However, if the equation size is increased, the equation becomes clipped, while shrinking the equation introduces a gap.
Although the use of a control panel makes it possible to resize equations, it is obviously desirable to have this happen automatically. This requires that the equation be rendered dynamically, and that the rendering be done with an awareness of the surrounding context on the HTML page.
To match appearances with the surrounding text, a math renderer must have runtime access to
- font family, weight, size and color
- background color, and link color scheme
At present, Java applets, ActiveX controls, and plug-ins can do dynamic runtime rendering of equations, but they do not have adequate access to the surrounding context, and they cannot adequately specify the size and alignment of their "windows" on the page.
Note: These features have been announced for future versions of Netscape.
Example 6: Consider once again your printout. You will note that the WebEQ equation did not appear at all. Although it is possible for a Java applet to generate a print job, it cannot print in context, that is, as it appears in the surrounding HTML page. Even if it could, the rendering would be sub-standard, since font metrics for printer fonts are not available. Work around solutions for printing exists, but none are very satisfactory.
Example 7: Note that moving your cursor over the WebEQ applet brings up a message in the status line. Ideally, one would like to have as much interactivity as possible for an HTML Math equation. At a minimum, it should be possible to link parts of equations such as the exponent x by itself, and the number 10 by itself. This is possible with an image via an image map, but then one loses the ability to give a meaningful cue on come up in the status line. An applet can do a much better job.
Some of the interactivity features that would be particularly useful for technical text are the ability to give cues on the status line, highlighting and linking parts of equations, and the ability to cut and paste equation mark up by selecting the equation. Another feature that is very important with long mathematical expression, which frequently arise in computer algebra output for example, is the ability to fold and unfold parts of an equation.
Most of the functionality described in the preceding paragraph is already available to plug-ins, applets, etc.
Example 8: If you search the source text for "= 10" you won't find the equation contained in the image in example 1. On the other hand, you will find that same equation, rendered by the WebEQ applet. Closely related to the ability to cut and paste equation mark up is the ability to offer equation mark up to other applications as well. Making it available to the browser for searching is a trivial example; adding an ALT tag to an image with the associated mark up solves this problem (though at the cost of making the authoring more difficult). However, one can easily imagine a situation where an equation should dynamically communicate with another applet or plug-in. For example, an equation might describe the state of a simulation applet embedded in the same page.

Advanced Examples

The degree to which a HTML Math renderer can determine its context ultimately determines how seamlessly math can be embedded in text. Of course, a native browser implementation provides complete context information. Some of the more detailed context information required by a plug-in implementation arises in situations such as these:

Example 9: In order to do line breaking for lengthy expressions (which occur very commonly in computer algebra system output) a renderer would need current screen geometry information. For example, the following image is too wide if your screen resolution is set at 640x400, and too narrow if it set at 1240x760.
Example 10: A renderer should also be able to detect whether an equation is in-line or displayed. This is because the same equation, for example , should be typeset differently when it appears in line than when it appears displayed:
Example 11: In the most sophisticated implementation, a plug-in renderer needs access to global context information. One example would be the inclusion of an anchor within a long HTML Math expression, which would require the renderer to set global context information. However, a more important application of sophisticated context information for HTML Math requires very little interaction with the rest of HTML. The ability to use scoped macros is of central importance in making HTML Math a powerful and flexible tool for scientific communication. This requires the ability to define macros within an HTML page, and the ability on the part of the renderer to detect when it lies in the scope of a macro definition.

Implementation Goals

By considering the examples assembled above, a short list of overarching implementation goals emerges:

Implementation Goal 1: HTML Math equations should render in accordance with user viewing preferences, and at the highest quality possible given the capabilities of the platform.

The two primary stumbling blocks to the widespread acceptance and use of the Web for technical documents are the unacceptably poor rendering quality of technical notation that current image based methods produce, and the difficulty of authoring technical Web documents. These make the cost/benefit ratio too low for widespread acceptance.

Implementation Goal 2: HTML Math equations should print properly and at high quality, printer resolutions.

In order to be widely useful, it must be possible to print technical Web documents. Image based methods provide unacceptable print quality, while other methods are either undependable, platform dependent, or simply non-existent. The overhead and inconvenience of maintaining a printable version and an electronic version of a document has proven itself too great for widespread acceptance.

Implementation Goal 3: HTML Math equations should be able to react to mouse gestures, and coordinate communication with other applications through the browser.

To be useful in a hypertext environment, at a minimum, HTML Math equations need the same linking support as surrounding HTML text. In particular, this includes the capability to link parts of equations. To be useful in a hypermedia environment, HTML Math equations need to be able to react to mouse gestures and coordinate communication with other applications in more sophisticated ways. A basic example is the ability to respond to a search engine with a linear as opposed to graphical form. A more advanced example might include interaction with a VRML viewer, or a Java applet.

Interface Requirements

A cursory examination of the implementation goals stated above show that current browser image handling and plug-in interfaces are not sufficient to achieve them. A more detailed analysis suggests a full implementation would require a number of browser enhancements:

Implementation Goal 1: HTML Math equations should render in accordance with user viewing preferences, and at the highest quality possible given platform capabilities.

Browser Interface Requirements:

the ability to query the browser for context information, such as whether the equation is in-line or displayed, and the ambient font size and family.
the ability to use the context information provided to specify equation size and alignment in terms of ascent and descent relative to the current baseline.
the ability to be informed of context changes, and to update the display accordingly.
The litmus test here is whether a user can change font sizes, and have the equations scale to match the surrounding text, both in size, style and rendering quality.
Status: According to pre-release documentation, applets and plug-ins will have access to context information, and have the ability to use it for alignment in Netscape Communicator. The ability to react to context changes may or may not be possible.

Implementation Goal 2. HTML Math equations should print properly and at high quality, printer resolutions.

Browser Interface Requirements:

the ability to access the same system printing information that is available to the browser.
the ability to render equations for printing within the larger HTML page.
The litmus test in this case is simply whether one can click the print button on the browser and obtain a well typeset document of uniform quality, including mathematical notation. Status: Printing capabilities do not seem to be significantly improved for applets and plug-ins in Netscape Communicator. Some work around methods are available.

Implementation Goal 3. HTML Math equations should be able to react to mouse gestures, and coordinate communication with other applications through the browser.

Browser Interface Requirements:

the ability to process mouse gestures over the equation
the ability to make browser calls for fetching URLs
the ability to make either browser or system calls to implement cut and paste functionality.
There is no single litmus test issue for interactivity; however, flexible linking and the ability to cut and paste equations into other applications such as computer algebra systems are probably the dominant examples to keep in mind. Status: These capabilities are largley available now to applets and plug-ins. Further enhancements have been announced for Netscape Communicator.

Implementation Strategies

In this section, we compare and contrast the strengths and weaknesses of two obvious implementation strategies: image based methods, and plug-in based methods. Needless to say, a native browser implementation is ideal, if not financially realistic.

Image Based Methods

The simplest implementation strategy for HTML math is to use an image and mark up pair in a standard HTML page. With current browser technology, this could be implemented as a standard image, together with source mark up in an ALT tag. A somewhat better solution would involve the introduction of a MATH tag which contained fields for an image or images, the equation mark up, and possibly some printable object.

Screen Rendering Quality With this method, screen rendering is unacceptably poor. As noted above:

Images don't scale
Alignment is poor
Use of anti-aliased fonts is not possible

Print Rendering Quality Although printing is possible with this method, print quality is again unacceptably poor, since the screen resolution is significantly lower than printer resolution.

Interactivity The only direct interactivity possible with this method is a link surrounding an entire equation, or the use of an image map, which is in general unreasonably complicated. By viewing the source text, it is possible to extract the original mark up. On the other hand, this is enough for external applications to properly process or convert HTML Math documents.

Other Considerations Large documents with many image files are bulky and slow to load. This is a very significant drawback for the majority of readers. Even a document of moderate length can take a long time.

A second factor is that hand editing is difficult, and typically involves a good deal of specialized software. The standard tool used in academia is latex2html which requires a user to install Perl, TeX, Ghostscript, and the PBM libraries. Moreover, converting from a source document to an HTML document is slow. Regardless of whether better conversion tools become available, it is inherently inconvenient and troublesome to have to maintain two versions of a single document.

Probable Improvements Two important devolpments are likely to make image based strategies more viable:

Network Fonts -- A large majority of mathematical notation in scientific documents consists of an isolated symbol or two. Network font systems, such as TrueDoc from BitStream, provide a way of utilizing standard symbol fonts in HTML documents.
Authoring Tools -- A number of software vendors have announced plans to implement support for HTML Math in their products. This will remove a major stumbling block to the widespread use of the web for scientific documents, regardless of the underlying implementation strategy.

Possible Improvements Several simple browser interface improvements would increase the effectiveness of this method:

Baseline alignment of images -- should be available through the use of PNG images.
Cutting and pasting the <ALT> tag text directly when an image is selected.
Printing at image resolution, as opposed to screen resolution.
Automatic selection of different images keyed to font size.

Plug-in Based Methods

A much more powerful and flexible strategy for implementing HTML Math involves using some sort of external processing program which interfaces with the browser. Options available using current technology include Java applets, Netscape plug-ins and ActiveX controls. We will generically refer to all these types of modules as plug-ins.

Although an HTML Math implementation is possible using current plug-in interfaces and HTML invocations, a better solution would involve introducing a new <MATH> tag, just as in the case of image based methods, along with a number of interface enhancements as suggested above.

Screen Rendering Quality With this method, screen rendering quality is in theory only limited by the platform. However, this is not the case with currently available browser interface APIs:

Plug-ins have the same alignment limitations as images
Plug-ins cannot resize themselves after they load
Plug-ins cannot adequately query the browser for the surrounding appearance context.

Print Rendering Quality Print quality varies with the kind of plug-in. It is not possible to print directly in context at all using only Java. It is possible to print in context with ActiveX controls and Netscape plug-ins.

Interactivity Fairly sophisticated interactivity is possible through the use of a plug-in. Complex linking, cutting and pasting, long expression folding, and even interprocess communication are all possible.

Other Considerations In theory, a plug-in solution solves the bandwidth problem that an image based solution presents, in that the HTML document need only contain the equation mark up. There is a one time cost for installing a plug-in or downloading a Java archive, but mechanisms for doing this efficiently or even automatically are already well developed. On the down side, plug-in solutions require current generation browsers on graphics capable platforms.

In practice, the Java implementations available in the current generation of browsers leave a good deal to be desired. Many of the weaknesses are quite technical in nature, and thus won't be detailed here. However, many important improvements have already been announced for Netscape Communicator.

Possible Improvements The browser interface enhancements necessary for full HTML Math implementation via plug-ins are those listed above.

Last modified: Wed Apr 30 13:39:46 1997