Some updates on the MathML Acid Tests...
First the patch for bug 717546
landed in Nightly and thus Gecko is now the first layout engine to pass the MathML Acid2 test.
Here is a screenshot that should look familiar:
As you know, Google developers forked Webkit and decided to remove from
Blink all the code (including MathML) on which they don't plan to work in the
short term. As a comparison, here is how the MathML Acid2 test looks like in
Chrome Canary:
Next, someone reported that Firefox Mac got more
errors in the MathML Acid3 test.
I was already aware of some shortcomings anyway and thus took the opportunity
to rewrite the tests with a better error tolerance. The changes also fixed some
measurement issues with auto resizing on mobile platforms or when the zoom
level is not set to the default. I also made the tests for stretchy operators
more reliable and as a consequence, Gecko lost two points: the new score is
60/100. I still need to review and describe the tests and hope I won't find
more mistakes.
Finally, I also added a MathML Acid1 test.
It does not really look like the "classical" Acid1 test and is not "automated",
in the sense that a reader must carefully (and in a subjective way) check the
basic
requirements. But at least it provides a small test in the spirit of CSS
Acid 1: all 100%-conformant HTML 5 agents should be able to render these very
elementary MathML expressions. Note that the formulas in the MathML Acid1 test
are supposed to express mathematical properties of boxes from the CSS Acid1
test.
There has recently been discussion in the Mozilla community about Opera
switch from Presto to Webkit and the need to preserve browser competition and
diversity of rendering engines, especially with mobile devices. Some people
outside the community seem a bit skeptic about that argument. Perhaps a
striking example to convince them is to consider the case of MathML where
basically only Gecko has a decent native implementation and the situation in
the recent eBooksworkshop
illustrates that very well: MathML support is very important for some publishers
(e.g. for science or education) but the main eBook readers rely
exclusively on the Webkit engine and its rudimentary MathML implementation.
Unfortunately because there is currently essentially no alternatives on mobile
platforms, developers of eBook readers have no other choices than proposing a
partial EPUB support or relying on polyfill....
After Google's announce to remove MathML from Chrome 25, someone
ironized on twitter about the fact that an Acid test for MathML should be
written since that seems to motivate them more than community feedback. I do
not think that MathML support is something considered important from the point
of view of browser competition but I took this idea and started writing MathML
versions of the famous Acid2 and Acid3 tests. The current source of these
MathML Acid tests is available on GitHub. Of course, I believe that native
MathML implementation is very important and I expect at least that these tests
could help the MathML community ; users and implementers.
Here is the result of the MathML Acid2 test with the stable Gecko release.
To pass the test we only need to implement negative spacing or at least
integrate the patch I submitted when I was still active in Gecko developments (bug 717546).
And here is the score of the MathML Acid 3 test with the stable Gecko
release. The failure of test 18 was not supposed to happen but I discovered it
when I wrote the test. That will be fixed by James Kitchener's refactoring in
bug 827713.
Obviously, reaching the score of 100/100 will be much more difficult to achieve
by our volunteer developers, but the current score is not too bad compared to
other rendering engines...
For those who missed the news, Google Chrome 24 has recently been
released with native MathML support. I'd like to thank
Dave Barton again for his
efforts during the past year, that have allowed to make this happen.
Obviously, some people may ironize on how long it took for Google to
make this happen
(Mozilla MathML project started in 1999)
or criticize the bad
rendering quality. However the MathML folks, aware of the history of
the language in browsers, will tend to be more tolerant and
appreciate this important step towards MathML adoption.
After all,
this now means that among the most popular browsers,
Firefox, Safari and Chrome have MathML support and
Opera a basic CSS-based implementation. This also means that about three
people out of four will be able to read pages with MathML without the
need of any third-party rendering engine.
After some testing,
I think the Webkit MathML support is now good enough to be used on
my Website. There
are a few annoyances with stretchy characters or positioning, but in
general the formulas are readable. Hence in order to encourage the use
of MathML and let people report bugs upstream and hopefully help to fix
them, I decided to
rely on the native MathML support for Webkit-based browsers. I'll still
keep MathJax for Internet Explorer (when MathPlayer is not installed) and
Opera.
I had the chance to meet Dave Barton when I was at the Silicon Valley
last October for the GSoC mentor summit. We could
exchange our views on the MathML implementations in browsers and discuss
the perspectives for the future of MathML.
The history of MathML in Webkit is actually
quite similar to Gecko's one: one volunteer Alex Milowski
decided to write the initial implementation. This idea attracted more
volunteers who joined the effort and helped to add new features and
to conduct the project. Dave told me that the initial Webkit
implementation did not pass the Google's security review and that's why
MathML was not
enabled in Chrome. It was actually quite surprising that Apple decided
to enable it in Safari and in particular all Apple's mobile products.
Dave's main achievement has been to fix all these security bugs so that
MathML could finally appear in Chrome.
One of the idea I share with Dave is how important it is to have native
MathML support in browsers, rather than to delegate the rendering to
Javascript libraries like MathJax or browser plug-in like MathPlayer.
That's always a bit sad to see that third-party tools are necessary to
improve the native browser support of a language that is sometimes
considered a core XML language for the Web together with XHTML and SVG.
Not only native support is faster but also it integrates better in the
browser environment: zooming text, using links, applying CSS style,
mixing with SVG diagrams, doing dynamic updates
with e.g. Javascript etc all of the features Web users are familiar with are immediately available.
In order to illustrate this concretely, here is
a couple of demos. Some of them are inspired from the
Mozilla's MathML demo pages, recently
moved to MDN. By the way, the famous
MathML torture page is now
here. Also,
try this test page to quickly determine whether you need to install
additional fonts.
MathML with CSS text-shadow & transform
properties, href & dir attributes as
well as Javascript events
HTML and animated SVG inside MathML tokens
MathML inside animated SVG (via the <foreignObject> element):
Note that although Dave was focused on improving MathML, the language
naturally
integrates with the rest of Webkit's technologies and almost all the demos
above work as expected, without any additional efforts. Actually,
Gecko's MathML support relies less on the CSS layout engine than Webkit
does and this has been a recurrent source of bugs. For example in the
first demo, the
text-shadow property is not applied to some operators
(bug
827039) while it is in Webkit.
In my opinion, one of the problem with MathML is
that the browser vendors never really shown a lot of interest in
this language and the standardization and implementation efforts were mainly
lead and funded by organizations from the publishing industry or by volunteer
contributors.
As the MathML WG members keep repeating, they would love to get more
feedback from the browser developers.
This is quite a problem for a language that has among the main goal
the publication of mathematics on the Web.
This leads for example to MathML features
(some of them are now deprecated) duplicating CSS properties or
to the <mstyle> element which has most of its
attributes unused and do similar things as CSS inheritance in an
incompatible way. As a consequence, it was difficult to implement
all MathML features properly in Gecko and this is the source of many bugs like the one
I mention in the previous paragraph.
Hopefully, the new MathML support in Chrome will bring more
interest to MathML from contributors or Web companies.
Dave told me that Google could
hire a full-time engineer to work on MathML. Apparently, this is
mostly because
of demands from companies working on Webkit-based mobile devices or
involved in EPUB. Although I don't have the same impression
from Mozilla Corporation at the moment, I'm
confident that with the upcoming FirefoxOS release, things might change a
bit.
Finally I also expect that we, at MathJax, will continue to accompany the
MathML implementations in browsers. One of the ideas I proposed to the
team was to let MathJax select the output mode according to the
MathML features supported by the browser. Hence the native MathML support
could be used if the page contains only basic mathematics while MathJax's
rendering engine will be used when
more advanced mathematical constructions are involved. Another goal
to achieve will be to make MathJax the default rendering in Wikipedia,
which will be much better than the current raster image approach
and will allow the users to
switch to their browser's MathML support if they wish...
People writing mathematics in emails, like researchers in mathematics or
physics, have probably encountered this difficulty to properly format complex
mathematical formulas. The most common technique is just to write text with
LaTeX-like or ASCIIMathML-like syntax and hope that the recipient will just
understand the expressions. Obviously, this is not really convenient to write
and read, some errors may happen and result in misunderstandings between the
sender and the recipient. There are other classical issues like how to write
the math (special syntax? math panel? handwriting recognition?), accessibility,
rendering quality etc Of course, these issues are well-known and expected to be
addressed by MathML. Since HTML is a common format for email and MathML is now
part of HTML5, this is clearly a good candidate to solve the problem of
mathematics in emails.
The idea to use MathML in emails is not new and was already suggested in a
screenshot from the Mozilla MathML Project more than 10 years ago.
Thunderbird has been able to render MathML in
newsfeeds for a long time, provided that the author served his content as
XHTML. I may also mention Amaya, which added support for sending a document by
email in 2007, although I have never figured out how to configure it to send
emails. Two years ago, I tried without success to fix a bug to display XHTML
attachment inline and which could be a partial solution to the problem.
Finally, one year ago Bob Mathews (from Design Science) asked me about the
status of MathML in Thunderbird, and I could unfortunately not give him a
better answer than what is in the present paragraph. But I hoped that MathML in
HTML5 will change the situation.
Indeed, while I was working on some MathML-in-clipboard patches, I realized
that it is now possible to paste MathML inside an email. After further
discussions with Bob Mathews, Paul Topping & David Carlisle, I've been able
to do more testing. The situation is the following:
Thunderbird can send emails containing MathML and render them
correctly.
Apple Mail (used in Mac OS X and iOS) can receive emails containing
MathML and should render them correctly since MathML
is enabled in Apple's products.
Microsoft Outlook does not render MathML in emails. However the rendering
is based on Microsoft Word which has MathML support. Basically, Thunderbird
sends MathML in HTML5 and Word displays MathML after an XSLT conversion
into Microsoft's own OMML format. Hence Microsoft might be able to do
something not too complicated to make the whole stuff work.
Web Mail Clients like Gmail or Zimbra seem to filter the MathML in emails
and so do not render it correctly. If this filter is removed, they can
certainly let the browser do the rendering job or use MathJax to do so.
Now let's consider a basic example about how to send MathML in emails, using
Thunderbird. One of the issue is that Gecko's editor has really been designed
with only HTML-editing features in mind and if you start editing MathML formulas you are
going to get some invalid markup messages or other troubles. And of course
Thunderbird does not have any math panel or other WYSIWYG tools to write
mathematics. However it might not be too difficult to write an add-on to add
MathML editing features in Thunderbird like BlueGriffon's
add-on or Firemath (these add-on
might even be installed without too much trouble in Thunderbird). Or one can of
course use one of the existing
tools to generate MathML and just paste the code in Thunderbird. Here I'm
going to use the itex2MML filter. So first write your mail in a
separate text file:
mail.txt
Hi Matthew, I just read your email about the behavior of the factorial function and harmonic series for large values of $n$. If you denote by $\gamma \approx 0.5772156649$ the Euler's number, by $e \approx 2.7182818284$ the Euler's constant then you have the well-known Stirling's approximation:
$$n! = \sqrt{2 \pi n} {\left( \frac{n}{e} \right)}^n \left( 1 + O \left( \frac{1}{n} \right) \right)$$
where of course I use the classical constant $\pi \approx 3.1415926535$. We also have the following asymptotic expansion:
$$\sum_{k=1}^n \frac{1}{k} = \ln(n) + \gamma + O \left( \frac{1}{n} \right)$$
I hope that this answers your question.
then call itex2MML to replace the LaTeX code by
<math> elements:
cat mail.txt | itex2MML > mail.html
Write a new mail in Thunderbird and use the menu "Insert ; HTML" . David
Carlisle told me that you have to be sure that the "send as HTML" is enabled if
it does not show up. Then just copy the mail.html source into the
window:
Once you click the insert button, the MathML should be automatically
rendered in Thunderbird:
When your email is ready, just send it as usual! Here is how it appears on
an iPod:
Let's just hope that other mail clients will support MathML in emails!
I wanted to wait for my oral defense before blogging about my master thesis
and how I manage to publish Web and paper versions of it. However, I finally met
my supervisor today and the oral defense is only likely to take
place next Wednesday. I do not want to delay too much this blog post and
thus decided to publish it today...
This year, I have taken the following approach to write my master thesis:
from LaTeX input files, I used XeLaTeX to generate a pdf document and LaTeXML
to generate HTML+MathML Web pages. I had to handle some small differences via
separate configuration files. However in general, these two tools are compatible
and accept more or less the same LaTeX input. I did not really have to make
graphics: I only used the amscd package to draw simple commutative
diagrams and did not try to draw schemas for representations of quantum groups.
Hence I did not get the opportunity to test how LaTeXML can generate
MathML inside SVG, although I saw on July something interesting for Firefox on
the LaTeXML mailing list.
The pdf version provides a good print layout which allows to workaround
some issues that I had two years ago when I printed
my Master Thesis
in Computer Science directly from Firefox. XeLaTeX also seems much faster
and so more convenient to use when you only want to check that your LaTeX code
is syntactically
correct and get a quick preview. It seems that XeLaTeX uses a kind of cache:
there are intermediary files that I guess are used again when you regenerate
the document. In contrast, LaTeXML seems to always regenerate one big XML file
in a first step and the Web pages in a second step. Perhaps LaTeXML has an
option to avoid that behavior or perhaps the idea of a cache system
does not work well in the case of Web pages.
The output of LaTeXML has the classical advantages of HTML+MathML for
publication on the Web and is much more comfortable to read on a screen.
Generally speaking, I think Firefox renders pretty well the LaTeXML output.
LaTeXML generates HTML rows to implement labelling and does not rely on
mathvariant, which allow to avoid issues with
<mlabeledtr> and token elements. However, I still note some
MathML's rendering imperfections which, not surprisingly, have already be
mentioned in the MathML
project roadmap:
Linebreaking: bad line breaks inside some equations, apparently those
generated by some environments like multline or
gathered. Sometimes, I also see bad line breaks around
equations for example when they are inside parenthesis.
Spacing: the lack of support for
mtable@rowspacing/columnspacing seems to give wrong spacing
inside binom-like notations. For some reason LaTeXML generates
<mpadded> elements of zero width in some places and they
cause weird overlappings in some summations.
Operator Stretching: commutative diagrams in the definition of Hopf
algebras would look better if we support stretching operators in table
cells.
This also gives me the opportunity to report various bugs and give some
suggestions to the LaTeXML team, including the use of MathJax (for
browsers without MathML support), the replacement of
<mfenced> by the equivalent <mrow>,
<mo> constructions (better rendering in Firefox),
improvement to the generation of headers in HTML5 and more.
