Gecko bugs blocking use of Native MathML in MathJax

[Frédéric WANG]

(I post this on Mozilla's MathML mailing list and cc' other people
potentially interested)

Dear all,

As you know, MathJax will be enabled by default in Wikipedia in a near
future. I've recently been looking again at the major bugs that prevent
Gecko's native MathML to be enabled by default in MathJax and how to fix
them. I give a summary below, based on the analysis of MathML code
generated by MathJax from LaTeX
(https://github.com/mathjax/MathJax/wiki/MathML-Support-In-Browsers) and
on other discussions with the MathJax team & users. Most of the issues
were already mentioned in my "Roadmap" blog post
(http://www.maths-informatique-jeux.com/blog/frederic/?post/2012/09/01/Mozilla-MathML-Project%3A-Roadmap).
Some workarounds can easily be integrated in MathJax's code and I've
prepared some patches for Gecko in order to fix the major issues. I
believe linebreaking support can be ignored for now, it is not enabled
by default in MathJax's SVG/HTML-CSS output modes so I don't think that
should be a strict requirement for native MathML either. Thus I guess it
will only remain to fix bugs like support for @rowspacing/@columnspacing
or better implementation of token elements.

Unfortunately, I don't expect to have much free time to work on Gecko's
MathML support in the upcoming year. So unless we find a way to fund
Gecko's MathML project, other volunteers will have to help. BTW, for
those who haven't read this article from Adam Hyde:
http://toc.oreilly.com/2012/11/math-typesetting.html. I'm not sure that
it will really help Gecko's MathML developments at the moment because
the publishing industry seems rather focused on Webkit. Perhaps
FirefoxOS will make more e-book companies interested in Gecko's MathML
for EPUB, but that will clearly not happen soon. Anyway, let's consider
the list below and hope we will figure out a way to achieve the goal of
making Gecko's MathML enabled in MathJax again.

1) Font support:

- Using fonts from MathJax's CDN:
https://github.com/mathjax/MathJax/issues/301
- Stretching braces with MathJax fonts:
https://bugzilla.mozilla.org/show_bug.cgi?id=732832

The rendering without math fonts is still our worst bug. I trust this
can be fixed by using fonts from MathJax's CDN. It will still possible
that the horizontal braces are not stretched but I expect this issue to
be solved when the MathJax fonts are updated to use only one glyph for
the middle part of braces.

2) Spacing:

- @rowspacing/@columnspacing:
https://bugzilla.mozilla.org/show_bug.cgi?id=330964
- negative mspace@width: https://bugzilla.mozilla.org/show_bug.cgi?id=717546
- width of <mspace>/<mpadded> within <mtable>:
https://bugzilla.mozilla.org/show_bug.cgi?id=459363

Support for @rowspacing/@columnspacing is a natural continuation of bug
731667, that Quentin almost fixed. Regarding the second bug, I have a
small patch that adds partial support for negative mspace@width and will
cover MathJax's use cases. I've recently submitted a fix for the third one.

3) Linebreaking:

- https://bugzilla.mozilla.org/show_bug.cgi?id=534962

This will certainly be too much work to do for volunteers. Gecko
actually has a basic linebreaking algorithm for direct children of the
<math> element but MathJax always adds an explicit <mrow> ancestor (to
workaround measuring issues with the <math> element) so linebreaking is
never applied.

4) Operator Stretching:

- Embellished operator regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=687807

The easiest way to fix this bug would just be to revert some changes I
made to implement mrow-like embellished op. Karl also has some
suggestions to refactor our data transmission, but that will be more work.

5) Tabular elements:

- support for mlabeledtr: either
https://github.com/mathjax/MathJax/issues/356 or
https://bugzilla.mozilla.org/show_bug.cgi?id=689641
- columnalign: https://bugzilla.mozilla.org/show_bug.cgi?id=491384

Davide prepared a workaround for the lack of mlabeledtr support and I
think this will be ready for MathJax 2.2. However, we will still need to
fix incorrect width computation within <mtable> (see 2 above and 6
below). There's already a workaround for the columnalign bug in MathJax
and I hope Quentin's work on 731667 will fix it anyway.

6) Token elements:

- width of token elements within <mtable>:
https://bugzilla.mozilla.org/show_bug.cgi?id=415413
- @mathvariant: https://bugzilla.mozilla.org/show_bug.cgi?id=114365
- rendering of primes: https://bugzilla.mozilla.org/show_bug.cgi?id=442637

I hope the first will not be too difficult to fix, but I haven't looked
at the details yet. If fonts from MathJax's CDN are used, then common
mathvariant characters necessary for MathJax will be displayed
correctly. I believe MathJax uses an <msup> for the prime (as
recommended by the MathML REC) and so Gecko must handle this properly.
All these bugs could essentially be addressed by moving some treatments
of MathML token elements from nsMathMLTokenFrame to nsTextFrame (see bug
785956).

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Robert O'Callahan]

Thanks Frédéric!

On Fri, Nov 30, 2012 at 12:02 PM, Frédéric WANG <fred...@free.fr> wrote:

> 3) Linebreaking:
>
> - https://bugzilla.mozilla.org/**show_bug.cgi?id=534962<https://bugzilla.mozilla.org/show_bug.cgi?id=534962>

>
> This will certainly be too much work to do for volunteers. Gecko actually
> has a basic linebreaking algorithm for direct children of the <math>
> element but MathJax always adds an explicit <mrow> ancestor (to workaround
> measuring issues with the <math> element) so linebreaking is never applied.
>

What measuring issues?

Rob
--
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]

[Frédéric WANG]

On 03/12/2012 03:08, Robert O'Callahan wrote:
>
> This will certainly be too much work to do for volunteers. Gecko
> actually has a basic linebreaking algorithm for direct children of
> the <math> element but MathJax always adds an explicit <mrow>
> ancestor (to workaround measuring issues with the <math> element)
> so linebreaking is never applied.
>
>
> What measuring issues?
>

Here is the issue in MathJax tracker:

https://github.com/mathjax/MathJax/issues/88

I haven't tried to analyse where the problem comes from precisely, but I
suspect it is due to our incorrect intrinsic width computation, similar
to what's causing bad rendering of mtable in some circumstances. The two
bugs I mentioned in my initial post:

https://bugzilla.mozilla.org/show_bug.cgi?id=459363 (now fixed, BTW)
https://bugzilla.mozilla.org/show_bug.cgi?id=415413

Another possible candidate:
https://bugzilla.mozilla.org/show_bug.cgi?id=433064

In general, there are various issues due to the implementations of the
<math> and <mtd> elements that differ from the one of the other MathML
elements. A serious one is:
https://bugzilla.mozilla.org/show_bug.cgi?id=236963. So it's not so bad
if MathJax adds explicit <mrow>'s to workaround these issues. Anyway our
linebreaking algorithm does not really do what is expected by the spec
(essentially, to break at mathematical operators) so I don't think it's
a problem if it is not applied to MathJax-generated code.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Frédéric WANG]

On 03/12/2012 22:33, Peter Krautzberger wrote:
> Regarding 1) font support.
>
> Some thoughts.
>
> * Using the MathJax CDN is ok for now, though a dedicated folder on
> the CDN might make more sense to simplify the link structure (and give
> us some metrics).
> * I would also consider uploading the fonts to Google's webfonts if
> that's interesting. I still don't know if there are any ramifications
> (special licensing etc), so if anybody has insight, let me know.
> * I'm wondering if Firefox could somehow ship with the STIX fonts (or
> MathJax fonts). The CDN would still make sense as a fallback, but this
> seems more natural to just ship them. What are the technical, or legal
> difficulties with this?
>
> Peter.
I'm not sure I was clear but when I was talking about using fonts from
MathJax's CDN, I really meant "make MathJax's Native MathML Output use
the fonts from the MathJax's CDN". That's already partially the case:
MathJax inserts @font-face rules pointing to MathJax's fonts (e.g.
fraktur or calligraphic) in order to workaround issues with mathvariant
in Gecko. The idea is just to generalize that to make these fonts used
to stretch operators too. Allowing people to use @font-face rule
pointing to MathJax's CDN when Gecko's Native MathML is directly used in
pages is a different issue, I was really only considering here the case
when it is used via MathJax.

Personally, I think that making each application handle its own copy of
fonts, static libraries etc is bad software engineering practice.
Ideally, applications on a same operating system should try to share
resources as much as possible and let package management system handle
dependencies, versions etc Recent versions of Mac/iOS have STIX fonts,
recent versions of Windows have Cambria Math (that Gecko doesn't support
yet) and most Linux distributions may add dependencies to STIX fonts. I
believe FirefoxOS will ship with math fonts and I reported a bug to
Android that hopefully will result in STIX being integrated. So the idea
is to support as much font as possible and to use those available on the
system. One of the main goal is to support Open Type Math fonts. Again,
I didn't include this bug as I was considering what is necessary when
Gecko's Native MathML is used in MathJax.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Frédéric WANG]

On 04/12/2012 13:08, Davide P. Cervone wrote:
> Fred:
>
> I'm happy to add whatever CSS is needed for the NativeMML output jax
> to do this, if you can tell me what that is. Is everything ready in
> Gecko to make that work?
>
> Davide
I actually had something in my issue301 branch that adds these CSS
rules, but we didn't take it for MathJax 2.1 because there were sync
problems with MathJax (MathJax needs to have the fonts available before
measuring and resizing the text for example). So the idea is rather to
let Firefox render the math normally (possibly without MathJax fonts),
use the same mechanism as for the HTML-CSS output to download the
MathJax Web fonts and then force a reflow when fonts arrived.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Frédéric WANG]

On 04/12/2012 13:08, Davide P. Cervone wrote:
> Is everything ready in Gecko to make that work?

And yes, everything is ready in Gecko, we just have to sync Web fonts
downloading with MathJax. Some characters like horizontal braces are
missing though, we have to update MathJax fonts first (issue 316) and
then it will be straightforward to make Gecko support these operators.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Frédéric Wang]

For your information, I've added a section "The Team" on the developer wiki:

https://wiki.mozilla.org/MathML:Home_Page#The_Team

Feel free to add your name on this page.

--
Frédéric Wang maths-informatique-jeux.com/blog/frederic

[Frédéric Wang]