Extension:Math/Native MathML rollout (2024)

Tracked in Phabricator
Task T271001

The Math extension is transitioning to native MathML, thus replacing the rendering of math formulas via the Mathoid service.

A copy of this page https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Math/Native_MathML_rollout_(2024) will hopefully be kept up to date on the Beta wiki, so that the effects of the latest updates can be seen.

Comparison

SVG

$E=mc^{2}$

This below uses SVG. Today, in MediaWiki 1.42 (and as the case on most Wikimedia Foundation wikis) we render Math formulas into an SVG. These SVGs are linked as an HTML image, and served to the web from file storage, generated via an internal Node.js service that runs MathJax whenever MediaWiki saves or previews an edit. In addition to the SVG, this mode also outputs a hidden MathML element generated by the same Node.js service, for the benefit of machine-readable semantic web, portability, and accessibility (e.g. plain text in the clipboard in supporting browsers).

${\cfrac {x}{1+{\cfrac {\cancel {y}}{\cancel {y}}}}}={\cfrac {x}{2}}$

${\begin{array}{lcr}z&=&a\\f(x,y,z)&=&x+y+z\end{array}}$

MathML

$E = m c^{2}$

This below uses MathML. The Math extension for MediaWiki supports a new "native MathML" mode written in PHP. This turns math fornulas in wikitext source directly into MathML, using the HTML5 <math> element.

$\frac{x}{1 + \frac{y}{y}} = \frac{x}{2}$

$\begin{array}{lcr} z & = & a \\ f (x, y, z) & = & x + y + z \end{array}$

History

The Math extension was originally developed around texvc, an OCaml program compiled and invoked as shell command.

In 2014, the Mathoid service was introduced in addition to textvc. Over the years, this became feature complete (T78046) and added benefits over the status quo including improved legibility (SVG being naturally in high resolution, such as for Retina screens) and improved accessibility/portability of HTML5 MathML. The service used MathJax, which supported these features already. Mathoid was launched as a user preference (labelled "MathML with SVG or PNG fallback"). In 2016, based on a community request this was made the default on all Wikimedia Foundation wikis in 2016 (enwiki RFC , T131177).

In 2018, Mathoid also became the default for the Math extension and thus the MediaWiki release as used by third parties. In order to ease installation, this defaulted to the live wikimedia.org installation of RESTBase/Mathoid. At this time, support for the texvc software was discontinued to ensure consistent feature parity in wikitext syntax (which is important for portability of MediaWiki content across the Internet), and to reduce maintenance burden (T74240, T195871).

In 2019, it was decided to sunset RESTBase (RESTBase/deprecation, T262315, board). By this time, RESTBase and other services from the former Wikimedia Services team had also become unowned or under maintained. Various options were evaluated (T338429) of which native MathML came out as most desirable (T271001). Benefits include reduced operational costs and overall complexity (remove on-going maintenance and operation of the Node.js service, remove need for long-term SVG file storage, remove need for RESTBase database to map hashes to files for all third-party MediaWiki sites), as well as restoring independent operation of MediaWiki as a software, thus resolving the question of MediaWiki LTS support and a long-tail of use cases which became dependant on the live wikimedia.org service (local development, CI, old third-party installs, archival research/benchmarking of the software).

As of 2022, all major browsers support MathML. Chromium was the last to join, thanks to Igalia. Read more at https://mathml.igalia.com/.

NativeML gives the user control over the rendering, including custom rendering via browser extensions, and styling of individual portions of the math formula via CSS and user styles.

Please report bugs on Phabricator. Freel free to mention new bugs in comments, or attach as new sub task, under https://phabricator.wikimedia.org/T271001. This is where blocking bugs, testing, and rollout is tracked.

Example usage

In the wikitext source, Math formulas are written using LaTeX, like so:

What	Markup	Output
Mass–energy equivalence	<math>E=mc^2</math>	$E = m c^{2}$
Cancellations in fractions	<math>\cfrac{x}{1 + \cfrac{\cancel{y}}{\cancel{y}}} = \cfrac{x}{2}</math>	$\frac{x}{1 + \frac{y}{y}} = \frac{x}{2}$
Multi-line equations	<math>\begin{array}{lcr} z & = & a \\ f(x,y,z) & = & x + y + z \end{array}</math>	$\begin{array}{lcr} z & = & a \\ f (x, y, z) & = & x + y + z \end{array}$

Reported cases

Reported Bug that are sub tasks of task T375318 Native MathML mode formatting bugs and task T375238 Client-side MathJax rendering problems.

A table showing some of these cases can be found at Extension:Math/Native MathML/Reported Cases

Torture Test

The Extension:Math/Torture Test is a recreation of creation the original MathML torture test old version 20+ years old, and a newer new version from 2021 that allows different font's to be used. This shows both SVG and MathML rendering.

Triage October 2024

A large number of problems reported at en:Wikipedia talk:WikiProject Mathematics.

Safari on Mac OS

(1) Every diacritical accent renders incorrectly, e.g. \hat a renders with the accent overlapping the letter, (2) subscripts render incorrectly with wrong vertical positioning (but sometimes too high and sometimes too low), (3) \operatorname renders incorrectly, (4) \left\vert renders incorrectly, (5) \partial is too close to the letter, (6) f' is completely broken, (7) f^{(3)} has the superscript run into the letter, (8) a sqrt with a fraction inside renders with too thin a line on top, (8) arguably this is a poor way to achieve the result but \overset{\underset{\mathrm{def}}{}}{=} has the letters too widely spaced, (9) \overline{abc} renders with more or less a hyphen striking through the top of the b, (10) limits of \prod and \sum have incorrect vertical alignment and the \prod and \sum symbols themselves are too small, (11) \xrightarrow[T]{n\pm i-1} has the wrong size arrow and horrible alignment of the parts above/below, (12) \overbrace puts a normal-sized curly brace turned sideways over the middle of whatever is being braced which does not stretch and is anyway too small, (13) fraction bars are consistently not quite wide enough (aside from the vertical spacing issue), (14) \lim_{n \to \infty} has too much horizontal space around \to, (15) \int renders with a too small symbol and overlaps a following fraction, (16) x^3\, dx has too much space between parts, (17) 0.5 has too much space around the decimal point, (18) \binom{n}{k} uses parens that are too small, (19) \begin{Vmatrix} x & y \\ z & v \end{Vmatrix} has mismatched sizes for the surrounding ||, (20) \bigl( renders a normal sized paren instead of a larger one, (21) \begin{cases} ... uses a too small brace, (22) \begin{alignat} .. does not properly align at the indicated & points, (23) \begin{array}{lcl} does not respect the specified alignment directions, (24) \hline in an array does not render, and vertical lines indicated do not render at the correct widths, (25) | renders with too small a symbol not matching other brackets such as \langle, (26) kerning is poor for uppercase greek (too wide) and lowercase greek (mostly too tight, but some too wide), (27) blackboard bold symbols are too wimpy to be legibly double-lined, (28) \mathsf renders smaller than the other math fonts, (29) \pm is not vertically aligned correctly (too low), (30) parentheses sometimes overlap the content inside, (31) parentheses horizontal spacing with surrounding content is inconsistent and usually at least slightly incorrect, (32) apart from rendering the prime completely wrong in x' the spacing afterward is much too wide, (33) spacing between a regular variable and a following named function is too tight, (34) vertical positioning of lines in \begin{cases} is inconsistent, (35) spacing between numbers and a following variable is too tight, (36) spacing around \cdots is too tight, (36) spacing before ; is too wide, (37) \tfrac renders incorrectly (not small enough, vertical spacing too tight), (38) sqrts in fractions are too large and extend too far below the baseline.

Firefox on Mac OS

A naively scaled font being used for inline fractions and superscripts, etc. is still a problem here. Beyond that:

(1) diacritics are not quite correctly positioned, sometimes too low, sometimes not horizontally centered relative to the visual top of the letter, (2) the \hat symbol is the wrong shape, looking like a wedge instead of a hat and \widehat uses the same symbol, (3) \lVert z \rVert has too much horizontal space around the z, (4) \operatorname{d}\!t has the two letters overlapping (\operatorname is wrong for this use which should just be \mathrm{d}, but \operatorname needs to add space, which the negative space was added as a tweak to eliminate; this kind of tweak for the previous renderer behavior will be found all across wikipedia and any new renderer needs to have close enough spacing to the previous renderer to not break them all), (5) \nabla\psi has too much space between, (6) fraction bars are too thin, (7) dy/dx has too much space around the slash, (8) dy, dx have slightly too much space between letters, (9) f' is completely broken here too, (10) \ddot y needs the dots pushed slightly to the right, (11) \shortmid uses the same symbol as \mid, which is incorrect, (12) square roots have overlines which are too thin and don't align with the √ part of the symbol, (13) \setminus and \smallsetminus use the same symbol, which is incorrect, (14) := renders with too much space between, (15) 45^\circ has too small a circle, (16) \not\operatorname{R} has a misaligned strikethrough, (17) \textstyle \prod_{i=1}^N x_i has the top limit of the sum too high, and the limits aren't consistently aligned on the left, (18) \lim_{n \to \infty}x_n has too much space around the \to, (19) \int\limits_{1}^{3}\frac{e^3/x}{x^2}\, dx has a horizontally misaligned top limit, and not enough space between integral and fraction, (20) 0.5 has too much space around the decimal point, (21) \cancel{y} has a poorly aligned strikethrough (not vertically centered), (22) vmatrix and Vmatrix don't have enough space between content and surrounding delimiters, (23) smallmatrix does not render small, (24) \begin{cases} has a brace with a disproportionately thick stroke relative to the font and too much vertical space between cases, (25) alignat doesn't get alignment correct at the indicated &, (26) \begin{array}{lcl} doesn't apply the indicated alignment directions, (27) \begin{cases} doesn't have enough horizontal space between the brace and the content, (28) \hline in an array renders but doesn't go from edge to edge, and the outside lines aren't rendered thick enough, (29) \left / renders too small around large content, (30) |\bar{z}| renders with inconsistently sized/aligned || and neither side is correctly sized or aligned.

Chrome on Android (Pixel phone, default setup)

Diacritics tiny, too far above their letters
The operator font has a significantly larger x-height and heavier weight than the math variable font, and there is no space between the operators and their arguments
Greek letters are far too wide, out of scale with Roman
In differentials and derivatives, commas placed too close to the fractions they occur in, so close that they look like primes on the variables
Actual primes are placed tiny and high above the letter they modify, indistinguishable from diacritics
Ell does not look like a letter, and certainly not like an ell. Maybe it is a weird at-sign?
The radical sign is much heavier than its crossbar, with a visible gap where they should connect, and is too high and small, to the point that in the expression sqrt(x^3+y^3) it looks like the square root is only on the exponents and not on the whole expression. I assume this would only get worse for nested radicals.
In the overset alpha omega tests, the alpha is tiny compared to the omega, regardless of whether it is above or below. The gamma is also tiny.
The over-arrows, over-braces, and under-braces are sized for a single character regardless of what they are over
The "Arrows" example has gone full Zalgo (he comes). Characters all on top of each other. Totally unreadable.
In many cases the limits of the summations, products, and integrals touch the summation or product or integral sign. The summation and product signs are indistinguishable from capital sigma and pi, too small. The integral sign is also too small, looking more like a bold sans-serif text long-s. The same issue with limits touching the signs also applies to the bigcap and bigcup.
You would think rendering "0.5" would be so easy as to be non-problematic. You would be wrong. There is too much space around the decimal point.
The binomial coefficients only use text-size and text-weight parens. Even in the case of tbinom this is wrong (they look far too heavy).
The matrix left and right delimeters only use text size. This is never right. In the case where \bigl has been explicitly used, the size has not changed but now there is extra unnecessary whitespace between the delimeter and the matrix.
The cases and aligned formulas are not aligned. The cases left bracket is text size, which is never correct.
In "parenthesizing big expressions", both the "bad" and "good" examples look identical. Both are bad. All of these parenthesized expressions use only text-size delimiters, incorrect for all of them. Especially bad are the floor and ceiling functions on a vertical fraction, where the floor and ceiling delimiters are raised above the midline so they look like they are applying only to the top part of the fraction, changing the meaning. In the examples of nested parens with different size qualifiers, all render in a single size. For some reason the last of these examples, with the nested slashes, puts much more spacing around the forward slashes than the backslashes.
The examples with mathbf do not work. The result just looks like italic, at normal text weight. Boldface Greek is also identical to non-boldface Greek. Greek italic capitals are not italic (they are upright just like the default Greek).
The Roman typeface is actually displayed as sans-serif, but the sans-serif typeface is actually displayed as italic serif. The sans-serif Greek is sans-serif, but this is the same as for all other Greek; there is no change in visible appearance.
Mathcal produces the appearance that I would expect mathscr to produce (curly script letters). (See File:Mathscr-vs-mathcal.png for how these are supposed to look.)
Fraktur has no effect; it produces the same italic text that you would get by default.
In the text "an inline expression like [integral] should look good", it doesn't look good, because inline integrals should put the limits to the right but here they are placed vertically above/below, making bad line spacing.
I didn't go carefully through the individual examples at the end of the link but my general impression was one of ugliness, with many of the same problems above and some others (such as limits with infinity signs becoming too big and overpowering whatever thing they were supposed to be a limit for).