共用方式為

Rendering MathML in HTML5

  • 發行項

As you can see in this document, Presentation MathML is part of HTML5. This is very exciting, since HTML5 is becoming the primary new web standard format. You might think that this would automatically make it easy to render MathML in a browser. In fact, FireFox does a decent job of rendering MathML, having incorporated MathML into its HTML renderer quite a few years ago. WebKit used by Safari and some other browsers also has recently added support for MathML. The present post points out some of the things one needs to do to render MathML using the Microsoft Office display engines (LineServices and Page/TableServices). The form needed for these engines is closely represented by OMML in file formats. To convert MathML to this form, more has to be done than simple parsing of a MathML tree.

Many MathML constructs map nicely onto the LineServices model. For example, the elements <mfrac>, <msqrt>, <mroot>, <mfenced>, <menclose>, <msub>, <msup>, <msubsup>, <munder>, and <mover> all map directly to counterparts in the LineServices model. Some others map with minor manipulation, such as <munderover>, <mmultiscripts>, <mphantom>, and <mpadded>. The element <mtable> typically maps well onto the LineServices matrix object, although advanced cases of <mtable> are beyond the scope of the matrix object.

Integrals and n-ary objects have a more complicated relationship and need some processing to convert. MathML doesn’t have a single element for these objects, using various combinations of <msub>, <msup>, <msubsup>, <munder>, <mover> and <munderover> to do the job. In contrast, OMML has the element <nary>, which takes three subelements: the lower limit, upper limit and n-aryand, e.g., integrand or summand. The <nary> element is quite convenient, since you can change the number of limits and the limit placements using element properties instead of having to manipulate the corresponding MathML tree. To convert to <nary> from the various combinations of MathML elements, you need to recognize that an n-ary object is being represented by those combinations. A key part of this recognition is to note that one of the operators in a combination is a Unicode n-ary operator and then to interpret the surrounding subscripts and superscripts (or over/under elements) as limits.

Furthermore, delimited expressions can be represented just using operator <mo> elements surrounding text elements, with no clue that a delimited expression is involved except for the semantics of the delimiter operator characters. For example a parenthesized expression can be written in MathML as <mo>(</mo>content<mo>)</mo>.

Similarly a MathML linear fraction doesn’t use <mfrac> with a “linear”property (as in the LineServices model). Instead the linear fraction is represented by <mrow> numerator <mo>/</mo> denominator </mrow>. To convert this to the <f> object for LineServices, one has to carry out significant parsing.

In some ways the pattern recognition needed to convert Presentation MathML for use with LineServices is akin to that needed to convert the Unicode linear format for math for use with LineServices. In the Microsoft Office implementations of the linear-format and MathML converters, a subset of Version 2 of the TOM interfaces is used. A rich-text string stack is employed for converting infix expressions into the prefix form required by the rendering technology. This is similar to the code one might write to implement a scientific calculator. The human being prefers infix notation like a + b, while the calculator wants the operator first as in +ab, as in the old HP Polish-prefix calculators.

The bottom line is that complex parsing is needed to convert Presentation MathML into a form usable by math display engines such as those in Microsoft Office.

Comments