Robert Miner, my friend and colleague on the W3C Math Working Group died yesterday from liver cancer.
Robert has Chaired or Co-Chaired the group since it started, and has been active in developing standards for mathematics on the web at the W3C since at least 1996. He will be sorely missed.
As some of you may have seen on google+ With a bit of help, I have MathML working in Firefox Mobile on Android. The key observation (of Karl Tomlinson) was that I needed a recent version of the font I was using (dejavu serif) as older ones did not have the necessary glyphs to build up “stretchy” characters such as large brackets needed for mathematical display.
So I have added support for Firefox/Android to my javascript library for enabling mathml-in-html5 (Firefox all versions, IE+MathPlayer 6-10, Chrome, Safari, Opera are all supported to some extent).
This reminded me that I never actually announced its existence, hence this posting. The javascript is maintained in a google code svn repository at html5mathml, although you might want to start with the test/example file at test1.html
The code is all freely available, It is all under the MIT licence, except for the copy of the dejavu serif font which is available under its own custom free licence, included in the distribution.
The idea is that you write a conforming html5+mathml document and just add the line:
<script src="html5mathml.js"></script>
into the head of the document, adjusting the src attribute to point to a local copy of the files downloaded from the above location. Please do use local copies, googlecode is a source repository not intended for serving production code to be used. Depending on the client browser being used, this JavaScript file may use one of two css files or the above mentioned dejavu font, all of which are available from the source repository.
Comments fixes and experiences using more browsers all welcome, either here, or in email or on the www-math list.
Currently the primary javascript library for enabling MathML support in browsers is MathJax, so perhaps I should offer some comparison. MathJax does far more than html5mathml, and generally speaking produces better MathML display, however it is somewhat slower and perhaps harder to set up locally (although it now has a public CDN server distribution which simplifies things greatly if access to the server can be assumed).
MathJax includes parsers for Tex-like syntax as well as MathML; this library assumes the input is MathML and relies on the browser to parse it (although includes some fixup for pre-html5 legacy browser parsing.) MathJax can be configured to do its own MathML rendering using CSS, or uses the native MathMl rendering in the browser if available. html5mathml essentially just assumes that the browser has MathML support although it does include css similar to that used in the the CSS profile for MathML. As such it loads much more quickly and reveals the MathML capabilities of the browser.
I try to track browser developments as far as possible (IE10 preview + MathPlayer for example is supported) but this is a spare time activity and I don't have access to all platforms, so any comments or code contributions for other platforms is always welcome. Currently the largest component is the dejavu font, probably I should subset that to just the characters needed for stretchy symbols. IE10 will no doubt require some changes once the full version comes out, and hopefully there will be a version of Chrome using the webkit MathML rendering (as now used in Safari). Similar techniques may be used to enable svg-in-html in legacy browsers that only support svg in xml. An early version of this code, handling MathML and SVG on a smaller range of browsers was discussed in a posting I made to the NAG blog last year.
The NAG Blog, to which I contribute from time to time, has a permanent link to Mike Croucher's blog, Walking Randomly. I happened to notice his current article on parametric plotting. The parametric plots are demonstrated with an applet providing Mathematica generated plots and slider controls. Mathematica is a nice piece of software but I couldn't help but think that a modern web browser ought to be able to do this without help from an external application.
HTML (5) provides a canvas drawing API that ought to be able to plot a curve or two, and also built in slider form controls.
I've not used canvas before, but it turns out to be pretty trivial to use, and my attempt is shown below. If you have a canvas enabled browser the plot should appear looking like the plot shown in Mike Croucher's article. Below that should appear some input forms that allow you to change the parameters. These appear as slider controls if a browser understands the HTML5 markup for this (Chrome does in its dev channel version at least). In other browsers they appear as text boxes, which allow you to change the values. (Firefox (4+) and IE (9+) work this way.) The plot should be redrawn if you move the mouse off the form controls.
Actually I prefer the text entry control to the slider, as it is easier to exactly control the value. I'd hoped that the arrow keys could be used to step the slider, but as implemented in chrome at least, that isn't the case. No doubt with a bit more scripting such keyboard shortcuts could be added, but this will do as a first attempt.
e: 0 80
f: 0 80
g: 0 80
h: 0 80
i: 0 80
MathML and OpenMath have always had a shared history and more or
less documented ways of converting between them. Conceptually the
conversion is very simple and OpenMath symbol
abc could be expressed as the Content MathML symbol
<csymbol>abc</csymbol>. Successive versions of
MathML have in fact added features that made this conversion simpler
and better information preserving. MathML2 added csymbol which
is a better fit for OpenMath symbols than ci. In MathML1 and
MathML2 further information about the OpenMath Symbol would have to be
packaged into the definitionURL attribute. In MathML3 we added explicit
support for recording Content Dictionaries by adding a cd attribute to
csymbol.
Although the basic idea of the transformation was simple, the
details of the transformation were complicated by a desire to map to
the pre-defined MathML elements where available. So <OMS
name="sin" cd="trans1"/> should map to the MathML element
<sin/> rather than
<csymbol>sin</csymbol>.
The relationship between the predefined MathML Content MathML forms
and the simpler, more regular, but much more verbose, OpenMath syntax
was not formally specified by MathML so had to be specified as part of
the transformation to OpenMath. An early version of such a
transformation description is this 10 year old document still
available from the OpenMath site.
Conversion
between MathML and OpenMath.
Around the same time, the conversions were implemented in XSLT. The
original versions predated XSLT 1, although the versions currently
available from the OpenMath site use XSLT 2. Converting from OpenMath
to MathML:
om2cmml
and from MathML to OpenMath:
cmml2om.
The relationship between
<sin/> and
<csymbol>sin</csymbol>
may rightfully be seen as a purely MathML issue and not something that
should be a by-product of converting to the OpenMath form
<OMS name="sin"/> and so MathML3 introduced, for each
of its Content layout forms, an explicit rewrite rule
expressing the construct in Strict Content MathML which is a
restricted form just using csymbol.
Section 4.6 of Chapter 4 of the MathML 3 spec specifies an explicit
multi-pass algorithm applying these rewrite rules to convert any valid
Content MathML expression into an expression just using the restricted
Strict Content MathML vocabulary.
4.6 The
Strict Content MathML Transformation.
Conceptually a conversion to Strict Content MathML could be made which first converted to OpenMath, then converted back to MathML using a stylesheet that removed all the special case rules originally added to om2cmml and documented in the OpenMath report referenced above. This was in fact implemented and is how the majority of the Strict Content MathML examples in Chapter 4 of the MathML spec were constructed. However there were some choices to be made in the mapping specification and in some cases the old OpenMath stylesheets made different choices. Where feasible I updated the stylesheets to match, but one essential structural difference remained. cmml2om implements a typical XSLT depth first walk over the input document, applying whichever template matches at that point. However the working group felt that the exposition of the algorithm was clearer if it was expressed as a multi-pass algorithm where each rule is applied in order over the whole tree, with the result being passed on to the next stage, to be rewritten by the next rewrite rule. These two approaches usually produce the same result, but in edge cases where the order of transformations matter they produce results that are (baring bugs) mathematically equivalent, but are structurally different.
As a requirement for MathML3 to proceed to W3C Recommendation status, we needed to show that the algorithm in Section 4.6 was implementable and did the right thing. It was clear that while my conversion via OpenMath was fairly reasonable it wasn't implementing the algorithm as specified and didn't produce the specified results in all cases.
Fortunately Robert Miner (co-chair of the Math WG) stepped up and offered to implement the algorithm as specified. It was good that he did, as inevitably, implementation experience showed some gaps or inconsistencies in the first drafts of the algorithm, and the final published form is much improved as a result of this implementation.
The initial home of the new stylesheet was in the W3C member area of the W3C CVS repository. Recently Robert suggested that we make it public, and asked if I'd host it at my google code web-xslt project site, since it is there and hosts other MathML related XSLT stylesheets.
So Robert's implementation is now available (under W3C or MIT licen[cs]e) from google code: c2s.
Comments on the stylesheet are probably best addressed to the www-math mailing list, but comments may also be dropped here on this blog or on the google code wiki pages.
I'm delighted to announce that the MathML for CSS profile has been published as a W3C Recommendation.
http://www.w3.org/TR/2011/REC-mathml-for-css-20110607/
This had a dependency on CSS 2.1 which was also published today.
This completes the three REC-track documents produced by the MathML3-era Working Group, joining:
http://www.w3.org/TR/2010/REC-MathML3-20101021/
and
http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/
The MathML for CSS profile (most of the technical work for which was done by George Chavchanidze of Opera) defines how a subset of MathML may be implemented using CSS. This is useful for two reasons: Firstly, it highlights possible places where CSS could be extended to improve its expressive power (so allowing a larger subset of MathML to be implemented) or secondly, it may be viewed directly as an implementation of a useful subset of MathML (and is similar to the CSS stylesheet for MathML which is used for MathML support in Opera). As usual, comments are welcome here or on www-math@w3.org list.