Thanks @Physikerwelt for making this issue. I don't have a complete understanding of what symbol coverage these various fonts have, what fallback font(s) would be used for symbols not found in the chosen font, etc.

The basic technical question I have on this is:

The issue here goes far beyond the bug tracker. The problem is a fundamentally broken high-level process and completely unprofessional project management.

Or, for completeness, here is the full range of font sizes in LaTeX from \tiny to \Huge, rescaled to the same absolute size:

The letters are not smaller overall. The issue is that the strokes are very thin.

\nleqslant and \ngeqslant were just examples. There are a number of other affected symbols (i.e. symbols which do not render correctly in "client-side SVG" mode), beyond just the ones explicitly reported.

Can whoever fixes this also make sure that the problem is fixed at a fundamental level? I imagine there are probably other combinations of nested stuff that lead to the same outcome, but I didn't exhaustively test every imaginable combination.

You still haven't bothered to ask Wikipedians what issues they consider essential to fix, and you still haven't even triaged all of the reported issues.

The image included with this bug report doesn't appear.

Adding commands such as those found in the scalerel package is definitely intended as a separate feature request, not part of a bug report.

And also one about the issue of spacing getting really wonky in various contexts such as under overlines/overbraces and in fractions involving exponents?

Thanks, @MSantos, for adding a bunch of new tracker tickets.

The fundamental issue (which affects all versions of MathJax) is that there is no change of font for different sizes of symbols, so the same outlines are used irrespective of symbol size. In LaTeX running offline, different sizes of symbols use different outlines, which have had their shapes modified to suit the size. Symbols intended for small size rendering often have thicker strokes, simplified features, larger counters (spaces inside a letter), modified x-height, etc.

There are enough extant examples of \dots – and enough people are going to keep making more, even if the existing ones were somehow all changed – that I don't think it's reasonable to break this command, which authors expect to work.

Here's what their website says:

I'm not too worried about permalinks.

In the current "server-side SVG" mode, px and pt behave exactly the same.

Make sure that if these are rendered side by side, the appearance is the same. For some reason the two versions in your "after" screengrab seem to have different font sizes, so it's hard to tell.

The units advertised by https://en.wikipedia.org/wiki/Help:Displaying_a_formula are:
em, mu, ex, in, pc, pt, cm, mm

could be argued that is syntax we do not support

There are many more critical problems that should block deployment to not break many, many Wikipedia articles. Many of them haven't been given bug reports here yet, but you can see a list of reported issues at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/MathFormattingBugs

The best way to fix these issues would be to make sure to use the fonts from AMSFonts / AMSSymb for mathematical symbols. These are what Wikipedia has always used in the past, are used by the vast majority of LaTeX documents, and are what authors expect.

Is this related to the strange client-side SVG issue where two completely different types of prime symbols are used in: C'^{*\!}, C'?

This is all rendered with MathML? Yeesh, none of those looks amazing, and most of them are awful. If that's the current state, MathML doesn't seem ready for serious use.

If we want things to work as authors expect, and we want to get something adequate in the relatively short term, we should start by trying to use a version of Computer Modern for the letters, numbers, and basic math symbols, and the font from AMSFonts (which is intended for use with Computer Modern) for other math symbols.

The behavior of an explicit command like "mathop" should not depend on the font at all, but should be turning whatever is contained in it into some kind of symbolic unit, and then setting the space around that.

In my opinion, we should use the font from the amsfonts/amssymb package for all of the usual mathematical symbols, at least for the "client-side SVG" mode. This is what authors expect, what Wikipedia has always used in the past, and these fonts are freely available.

In LaTeX, the colon made by ":" is supposed to be a "mathematical relation" symbol. The spacing before and after must be the same as for other mathematical relation symbols like =, >, ≥, or →. This is subtly different than the spacing used for binary operation symbols like +, −, ·, or ×. The two types (mathrel vs. mathbin) also behave differently in different contexts.

Is there a version of this bug relevant to the "client-side SVG" mode? That seems like the more important one to address in the short term.

That one is marked as "resolved"; it looks like just matrices were special cased, and the underlying issue affecting all multi-line environments was not really addressed.

Trailing line breaks need to be ignored in every multi-line environment (align, alignat, array, cases, etc.).

The font size for math should be the same as the font size for adjacent text. Bumping the font size for all math is a terrible idea.

It doesn't matter what is causing the bug. This blocks deployment.

A few of the ones that must be fixed to avoid breaking many, many Wikipedia articles:

The horizontal length is about right, but the horizontal position is wrong. (The vertical position is also wrong.)

This seems to be an intentional change in upstream MathJax

Instead of bumping the deploy 1 week at a time every time it is a few days away, from one absurdly unrealistic date to a different equally absurdly unrealistic date, how about you work with Wikipedians to figure out which bugs are completely unacceptable, which ones need discussion, etc., and then put up some more plausible milestones that development needs to achieve?

All of the units {em, mu, ex, in, pc, pt, cm, mm} need to be supported and behave the same way between "client-side SVG" and "server-side SVG" mode, from all of the align-type environments (including also cases, matrix, etc.)

\overline{\alpha} is still incorrect in "client-side SVG" mode. It renders too close to the letter and is not properly horizontally aligned. (This should maybe be recorded as a different ticket.)

Here's what this looks like when rendered with LaTeX, using usual defaults:

I think it would be a somewhat okay size if we used a dedicated font for the smaller text. in the new default font for "client-side SVG" mode, which is already on the thin side for regular size, anything this small starts getting extremely thin, to the point it's hard to read

That is definitely far too generous. I'm just some guy on the internet who happens to care a lot about math education, math history, typography, and Wikipedia. It's not about what I personally think, in particular, but about the general group of Wikipedians who author and maintain technical articles, who are the main "stakeholders" of a change like this.

"Next week" is completely unacceptable as a date. We are still at least months away from something that isn't horrendously broken. You haven't even triaged most of the reported bugs.

Malparti: That specific example of the bug seems like it was triggered from having the text written on the same line as the image, without a line break between. It doesn't happen when inside a table cell, so I can't add the example to .../MathFormattingBugs, but here's a simple example that triggers the same issue:

I just don't understand how the current bug triage relates to the schedule posted above. Until there has been tickets filed, fixes attempted, some discussion of what is possible and impossible, etc., ideally with more stakeholders than are present on this ticket system, I don't think we can even propose a plausible date for deployment to English Wikipedia. At the apparent current pace, and apparent current lack of urgency, we're still many months of time and significant amounts of discussion away from that.

Most of the inconsistencies reported at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/MathFormattingBugs still haven't been turned into tracker tickets.

Can someone here give me some kind of LaTeX markup (possibly involving ugly workarounds) that will render this historical continued fraction notation in the "Client-side MathJax" mode?

Thanks, this is closer to the intention of \bar.

There's a pretty serious set of space-eating bugs that shows up in various contexts including under overlines, under overbraces, and in various combinations of fractions inside parentheses and parentheses inside fractions. Have they been given ticket(s) yet?

Is there any kind of ETA on when we might get support for a forcemathmode that forces the "client-side SVG" mode to be used, deployed to English Wikipedia? This is a really critical prerequisite to being able to get more feedback from Wikipedians about what kind of bugs they do or don't see in their browsers.

Are there already bug reports/fixes for these other two align-related bugs. Both seem critical to me:

The "server-side SVG" mode does the right thing:

If you want a slightly trickier example, you can try something like:

In alignat (unlike align) there should not be extra space between pairs. In LaTeX running on my local computer, your example renders as:

Let me re-upload. I think maybe when I edit a comment the newly added images get blocked.

I was under the impression that T435274 is more important as several regressions are related to it.

The above images are basically what I see, The spacing is all messed up and looks awful. We get examples like:

@Krinkle triaged T434424 as "low" priority, but that bug is a complete show-stopper which critically blocks any successful deployment of this feature on English Wikipedia. Thousands of articles rely on predictable behavior of the "align" and "alignat" environments.

MathJax version 4 has support for a range of different fonts. Have we tried evaluating all of the various options?

The worse so far

problems with the browsers rendering of MathML rather our generated mathml.

The "MathML" rendering is awful. Here's what it looks like in my browser (Safari 18):

Also, the "MathML" version looks like this in my browser (Safari 18):

This summary backwards. The "client SVG" behavior is wrong and the "server SVG" behavior is correct.

"look like" font issue are actually probably not

If you find at least 5 new bugs

For anyone who isn't participating on Wikipedia's Math Wikiproject talk page, a page at

A whole lot of the common math symbols used in the "Client side SVG" option are just bad for one reason or another. For example the ellipses have dots spaced too close together, the \big( size of parens is too big, the double-vertical \| symbol has the lines too close together, etc. Is there some reason we can't use the typical default LaTeX fonts (Computer Modern / amsfonts)? Thes are used in the "Server-side SVG", and are the default when MathJax is used independently on some external website; everyone is generally more or less satisfied with them.

@SalixAlba On your sandbox example, all three of the "forcemathmode=mathjax", "forcemathmode=mathml", and "forcemathmode=latexml" options do the same as the "SVG" (i.e. server-side SVG) preference option. None of them do the same as the proposed new default "Client side MathJax" option. So I don't know how to set up a meaningful test page showing to Wikipedians who haven't changed their preferences how the proposed new rendering option will affect their mathematical expressions.

@SalixAlba are you sure this works? Can you make an example hosted on English Wikipedia (e.g. in user or talk namespace somewhere) of these forcemathmode options in use? When I try to add forcemathmode=mathjax I get the same behavior as the current default (server-side SVG) and something different than what I get if I leave the option out and change my appearance preference settings.

Another question, so we can try to set up a page on Wikipedia with examples, take screenshots on various platforms, and better come up with a list of bugs:

As one basic question: does anyone know why the server-side rendered SVG and the client-side SVG use different versions of a Computer Modern font? The server-side rendered version is slightly bolder. The "client-side" one is very thin and spindly, and noticeably harder to read, especially for finer details and smaller symbols.

The main problem I see is that we are facing a tension between RESTBase / mathoid sunset, work that has been undergoing years now, and the math formulas UX on wiki content. The RESTBase sunset cannot be postponed without bringing other risks and costs.

you think we don't keep users in mind, thats your prerogative,

Aklapper: This is getting off topic, but I'm trying to criticize the process, not the people.

Rendering to SVG with MathJax, which is a determistic JavaScript code that produces an SVG.

If you haven't reviewed this within the past two months, or reviewed it with the MathML setting instead of the new "Client side MathJax" setting,

In T271001#12192310, @Aklapper wrote:

@Jacobolus: Please read https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette. Thank you!

Yeah, which means that the developers here haven't even looked at many of the basic examples in widespread use across Wikipedia. That's a huge failure on your part. You need to set up a comprehensive suite of examples, including both a wide range of simple single-feature examples and a number of complicated examples taken from technical Wikipedia articles. If you need help finding examples you should talk to Wikipedians, who will be happy to help you. Then you need to make sure that the examples all render correctly.

This is still nowhere close to ready for deployment on Wikipedia, at least with whatever version is currently included behind the "Client side MathJax rendering" preference.

Since this apparently requires including a math font (here, computer modern) along with MathJax, would it be possible to use the same font from other wiki CSS?

You missed a potential path forward: revert this change which has nothing to do with discussions per se, and let any wiki which wants add their own CSS rule implementing whatever extra space they want before or after the colon. This style feature should not depend on any change to Mediawiki software, and this misfeature was a pointless waste of developer and community time.

I think the reasoning here is: "we tried it and few people said anything, so it must be okay".

It's insane that this change got so much well-reasoned pushback here and then still managed to make it through to production. Something is profoundly broken in the software development process here.

"awaiting for MathML to be good enough across browsers" – You should plan on waiting for this forever, and then you can be happily surprised if it ever happens. Since currently shipping browsers are not there yet, the timeline for this being good enough is probably at least 5 years.

In practice, nobody ever discusses anything at Talk:Wikimedia Community User Group Math (perhaps because it is full of spam), and if you put a question there nobody will read it and it will serve no useful purpose.

The meta talk page Talk:Wikimedia Community User Group Math is completely worthless. There is zero meaningful discussion and mountains of off-topic Wikimedia organization spam. You should probably start at somewhere like the math wikiproject and maybe physics wikiproject on English Wikipedia. (I am not familiar with other language Wikipedias).

1. People testing the client-side MathJax mode on English Wikipedia still are making routine bug reports about pages that look fine with the previous default rendering but broken with the experimental rendering modes. All of those should be ironed out before anything like this can be made default.

As far as I can tell all of the browsers in "Grade C" and most of the browsers in "Grade X" currently receive the same high quality math typography from Wikipedia that the "Grade A" browsers get. So if you are suggesting that it's completely fine if every reader who doesn't have "Grade A" browsers or current hardware should receive ugly or even illegible mathematical notation, that would be a huge downgrade/regression compared to current support.

The page https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Math/Native_MathML/Reported_Cases has completely broken layout so that's not too encouraging. Also this just shows random snippets of formulas out of context, which is okay for testing certain specific features but doesn't do a good job of showing how mathematics appear in context in articles.

In my opinion the #1 requirement for any such potentially disruptive change is to set up a test environment with at least several dozen devices of various display size, operating system, browser, browser version (representing versions back maybe 10 years), and make a test page with a wide range of mathematical expressions drawn from wikipedia articles and shown with sufficient context so that they appear as they would in-article, and then get the rendering across devices evaluated by experts, with release blocked until there has been a sign off that rendering has consistently high quality. This would probably be easiest if a way were figured out to get screenshots of these automatically produced so they could be easily inspected remotely, rather than needing to bring someone to a physical place where the devices sit.

No you should most certainly not follow any plan like this. The native mathml mode remains completely unready for wide-scale production use, and switching to it as a default for any of the large language Wikipedias any time in 2025 is going to be a huge mess with lots of angry push-back from Wikipedians and Wikipedia readers. Many readers' browsers will render formulas in various broken ways, and most of the rest will have unacceptably ugly spacing and layout problems on many pages.

Math articles are still vaguely readable with this bug, but thousands of them have messed up formatting, in some cases pretty severe, and it's hard to get a good sense of what the appearance will be (once the bug is fixed) which slightly hampers editing in the mean time. If it takes two or three days to roll this back it's not the end of the world, but the faster the better.

In the mean time this can be worked around in two ways:

While we're at it, as you can see from Edtadros's screenshots above, the vertical alignment of inline math is also off, worse than it was yesterday.