| Physikerwelt | |
| May 16 2015, 3:31 PM |
| F242473: gecko-mediawiki.png | |
| Jul 24 2015, 8:19 AM |
| F199505: math rendering.png | |
| Jul 20 2015, 12:52 AM |
Client side MathJax rendering is outdated. There are browser plugins that support MathJax rendering for chrome. The advantage with those plugins is that they use the most recent actively maintained version of MathJax and do not require that users log in.
See also
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Bump version to 3.0.0 | mediawiki/extensions/Math | master | +1 -1 | |
| Remove client-side MathJax support | mediawiki/extensions/Math | master | +1 -161 K |
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Resolved | Physikerwelt | T87941 Convert Math to use extension registration | ||
| Resolved | Physikerwelt | T99369 Remove client-side MathJax rendering mode | ||
| · · · |
MathML is NOT a solution. MathJax has been a working solution at every other major mathematics site for six years now.
I understand the pragmatics of where you are coming from, really. But MathML has worked on Firefox since much before MathJaX was invented, and you can style it beautifully with some well-placed CSS, just as you style the rest of any wiki page. It's HTML5 as usual. SVG is also an HTML5 native, and it fits well on the open web, as you have well-defined cross-browser support for it already. Again, you can use well-positioned CSS to get as much beauty as you need.
MathJaX works, agreed. It is a wonderful bridge technology that is keeping the mathematically inclined citizens of the web actively thinking of "web-y" math, rather than dead bitmap images, and that is wonderful. But thinking that "simply" committing to MathJaX and moving on will solve the world's problems is a bit too risky a bet in my view.
Keep in mind a JS-based solution has a number of deficiencies, such as performance (high volume math pages take a long time to load), an added maintenance burden on MediaWiki (changes to MathJax need to be tracked and understood) and an added third-party dependency (if the MathJaX CDN falls, all math is gone).
While having beautiful math is the ultimate end goal for the editorial staff, having accessible, fast to render, standards-compliant math are also valuable aspects that will feed a number of ecosystems. Having an HTML5 native solution is definitely the way to go forward in my mind.
@Dginev: I don't care if it works in Firefox. It needs to just work, period. MathML is a distraction from that. It is diverting your attention from the actual problem, which is the not-logged-in view. MathML will never be the not-logged-in view and any developer work spent improving MathML is developer work wasted on not addressing the actual issue. We don't need to solve the world's problems to realize that the horrible state of mathematics formula formatting on Wikipedia is a major embarrassment to the project and that this particular change and other recent developer activity have zero chance of improving that situation.
Again, you are letting the perfect be the enemy of the good. "Accessible, fast to render, standards-compliant math" are nice things to think about having, but should be far far down in your priorities below "math that works well enough to persuade Wikipedia editors to actually use it". Because the accessible part is already taken care of by the TeX source option, and who cares if you have a boutique quick-rendering standards-compliant product when only a tiny fraction of logged-in editors ever see it, on the even tinier fraction of mathematics articles where the editors haven't just given up in total abhorrence and gone back to formatting equations with gross workarounds like "{{nowrap|1=2<sup>''k'' + 1</sup>''y'' =}} {{nowrap|1=σ(''x'') =}} {{nowrap|1=''x'' + ''y'' + other divisors =}} {{nowrap|1=2<sup>''k'' + 1</sup>''y'' + other divisors.}}" (actual markup from Euclid–Euler theorem)?
Making MathML the default is the plan as outlined here T78046. And I currently do not see evidence that this will not happen.
Because the accessible part is already taken care of by the TeX source option, and who cares if you have a boutique quick-rendering standards-compliant product when only a tiny fraction of logged-in editors ever see it, on the even tinier fraction of mathematics articles where the editors haven't just given up in total abhorrence and gone back to formatting equations with gross workarounds like "{{nowrap|1=2<sup>''k'' + 1</sup>''y'' =}} {{nowrap|1=σ(''x'') =}} {{nowrap|1=''x'' + ''y'' + other divisors =}} {{nowrap|1=2<sup>''k'' + 1</sup>''y'' + other divisors.}}" (actual markup from Euclid–Euler theorem)?
This workarounds are really annoying. I was extremy bothered by them in the context of my Mathematical Language Proecessing project that tries to automatically extract identifier definitions from the sourounding text. A mix from \TeX and UTF-8 is really hard to process.
You notice the "with PNG fall-back images" part of the T78046 outline that you linked to? That is what you're actually proposing as the default. I.e., the same bad solution that we've had for ten years and that has been an embarrassment for at least the last six since MathJax has existed and been shown to work everywhere else. If your solution is "X with fallback to Y" then the actual default is Y, and X is just an enhancement for a subset of the users, not any different in principle than what the MathML code is now.
And if you agree that the workarounds are annoying, what you should be doing is making the default rendering of math so good that nobody uses the workarounds. But the MathML code is not part of the default rendering and not relevant to that equation.
If your solution is "X with fallback to Y" then the actual default is Y, and X is just an enhancement for a subset of the users, not any different in principle than what the MathML code is now.
Only a minor percentage of users that still have IE6 will see PNG images. I don't agree to the claim of the default.
For example, if I would install an elevator to a subway station to enable wheelchair access this would still not be default.
Lets look at the difference in rendering between the different modes.
None of the renderings are quite upto printed LaTeX standards, each has its own glitches.
MathML seems to have a bit too much space in the derivatives, the size of some of the symbols seems to be a bit small. Theres a bad kerning issue with the derivative on the first line, there also a bit of a glitch at the top of the squareroot sign. I'm not sure about the size ratio of superscripts to main text, they seam a little big to me. It's pretty hard to distinguish between f' and f''.
The mathjax has the fewest obvious glitches. The equivilence sign in the modulus seems to have a bit of aliasing (none of the systems gets this character right). I might quibble over the placement of the three in the cube root. Subscripts could be a bit lower.
The glaring problem with the PNG is the aliasing artifact, the font size is also rather large. Apart from that its not a bad rendering.
Server side SVG is quite similar to MathJax, the font look a little bit darker, subscripts could be a bit lower. Theres rather too much white space around the surds and there is an aliasing affect in the horizontal lines.
If it were not for aliasing and font size issues I would say the PNG is the better rendering, this is probably not surprising as its used latex rendering system. Then comes the MathJax solutions (am I right in saying server side SVG uses mathjax somewhere?) The firefox MathML looks the worse. This is not too surprising as it does not look that much attention is being given to the MathML project https://wiki.mozilla.org/MathML:Home_Page with only one meeting this year. MathJax on the other hand is being much more actively developed.
If nothing else its the active development of MathJax which suggest this is the way to go. MathML is only acceptable on one browser.
@Physikerwelt: What you are actually proposing is "MathML with fallback to SVG with fallback to PNG" and many more users than just the IE6 holdouts will see the SVG-level fallback. For instance, as a Chrome user, that's what I see. I for one find the SVG fallback ugly enough versus MathJax (as detailed above) that I (as a long-term and high-volume Wikipedia mathematics editor) will likely continue using the workarounds. But it seems nothing will persuade you away from the bad track that you seem determined to continue pushing Wikipedia towards, nor your failure to have any concern for the interests of actual mathematics editors, nor from your efforts to keep MathJax away from Wikipedia.
MathML is not useful as a markup language because it is so horrible for humans to write and all actual mathematicians use TeX. It is not useful as a rendering language because modern browsers like Chrome don't render it. It is not usable for accessibility for the same reason it is not usable as a markup language: it's not written to be understood by humans, so it would have to be converted to something else, the something else that mathematicians understand is TeX, and converting Tex→MathML→TeX is worse than just using the human-written TeX. So all it seems to be good for is distracting people who think "standards compliance" is more important than usability into making Wikipedia work worse. But since again the refusal to use MathJax and the insistance on pushing the failed MathML language seems to be a fait accompli the only remaining thing to do for me seems to be to withdraw from this thread and publicize this outcome elsewhere as a bad example of how not to do mathematics.
Given that Chrome simply does not support MathML, has not supported it for years, and is not likely to support it for years more, MathML is a red herring. It's irrelevant to this discussion.
Realistically, the only two paths forward are MathJax and SVGs.
MathML is not useful as a markup language because it is so horrible for humans to write and all actual mathematicians use TeX.
As they should, MathML is a rendering language not an authoring language. People write markdown to get HTML, just the way they write TeX to get formulas. So this remark is irrelevant.
It is not useful as a rendering language because modern browsers like Chrome don't render it.
Interesting, I hadn't realized that a handicap of a browser is now considered a convincing argument against using a well-defined mature technology stack. MathML adoption has failed to be ubiquitous for some time, but mostly because the chicken-and-egg nature of adoption. The market needs to demand it for the providers to supply it, but the market won't demand it until they know it exists and it's capable of providing native support to ALL needs of mathematicians on the web. Again, MathJaX is a great bridge to that, and it quite successfully uses MathML as its internal representation language. Yet to me accepting MathJaX as the holy grail is equivalent to *giving up* on mathematics being an equal part of the world wide web. Sorry if my perspective sounds too high level, but having a MathML primary with a different fallback is a very good compromise in this regard that also offers a good way forward for math in Wikipedia. And you can install the MathJaX extension for your browser of choice, as mentioned earlier, nothing precludes that.
Being upset with @Physikerwelt is really missing the point here, and your perception of the complete failure of MathML is somewhat rushed. With the right perspective, any formula rendered by MathJaX today is also a MathML formula internally.
It is not usable for accessibility for the same reason it is not usable as a markup language: it's not written to be understood by humans, so it would have to be converted to something else, the something else that mathematicians understand is TeX, and converting Tex→MathML→TeX is worse than just using the human-written TeX.
Accessibility is achieved by machines, not by humans reading the annotations. Any developer would tell you that parsing TeX is insanity and that having any structured format (MathML and SVG being two great examples) is a godsend in comparison. Be it math-to-speech or transcribing math in Braille, having a structured format is a bare minimum in getting there.
As to the rendering, the important thing in comparing the default structured outputs is whether the trees look right. As I said previously, you can get to the MathJaX level of beauty of the symbols and operators by using the right fonts and styling in a CSS stylesheet.
This is not true. There is a third-party MathJax extension for Chrome and for no other browser.
Additionally, we should not require users to install a browser extension to get a usable experience. I don't even know if it's possible to install a browser extension on, say, my wife's iPad.
Any developer would tell you that parsing TeX is insanity and that having any structured format (MathML and SVG being two great examples) is a godsend in comparison. Be it math-to-speech or transcribing math in Braille, having a structured format is a bare minimum in getting there.
What you are saying is that developer convenience trumps user experience. It is nigh impossible for a user to edit MathML by hand. Any usable system must use something else, and that something else is TeX, nothing else having caught on in the past thirty-seven years. Insanity or not, TeX is inevitable. That does not make MathJax inevitable, of course, but it severely limits the possible use cases of MathML.
Additionally, it sounds to me like you would prefer to remove TeX support altogether. Please reassure me that I'm misinterpreting you. That would be the death of mathematics on Wikipedia.
Re: Additionally, it sounds to me like you would prefer to remove TeX support altogether. Please reassure me that I'm misinterpreting you. That would be the death of mathematics on Wikipedia.
That would be true insanity. Getting rid of any hope of moving to MathJax, the subject of the current discussion, will merely push me to use more wiki-workarounds and less <math> in my editing, and denounce MathML from the highest soapbox I can find, but is unlikely to change what or where I edit on Wikipedia itself. Getting rid of TeX markup altogether and forcing me to choose between a visual editor or MathML-as-markup for those hard-to-format big equations will more likely cause me to leave the whole project. Try looking up my contributions for how big a change that would be to me. Or, if you truly care about the future of math on Wikipedia, try listening to people who actually edit math there.
What you are saying is that developer convenience trumps user experience. It is nigh impossible for a user to edit MathML by hand. Any usable system must use something else, and that something else is TeX, nothing else having caught on in the past thirty-seven years. Insanity or not, TeX is inevitable. That does not make MathJax inevitable, of course, but it severely limits the possible use cases of MathML.
Again, MathML is not intended to be an authoring language. TeX is just as inevitable as using markdown, but that is in no way "a failure of MathML". It's pretty much completely out of scope of MathML, which is a rendering language first. The fact that no one is writing <video> elements by hand isn't a failure of HTML5, etc. So the claim that TeX authoring limits MathML is simply wrong, they solve different problems.
Additionally, it sounds to me like you would prefer to remove TeX support altogether. Please reassure me that I'm misinterpreting you. That would be the death of mathematics on Wikipedia.
Indeed you are misinterpreting me, my last message reaffirmed the necessity of using TeX for equations, I never suggested backing away from it.
It is worth pointing out that MathML seems to have failed to get caught on as a markup language (in terms of browser support for instance). This is probably unfortunate; I can understand MathML is a better solution than more ad hoc approach like MathJax.
But the important thing is to be aware of the reality. Many (actually all) major math-related websites like mathoverflow or math blogs use MathJax nowadays. It is strange to me that Wikipedia is taking a different path.
What you are saying is that developer convenience trumps user experience.
I'll address this separately and then stop, since I am starting to repeat myself.
It's a feat of great cognitive dissonance to see the failure of Chrome to add support for MathML, as a failure of MathML itself. If anything I find the leniency that Chrome is allowed to cherry-pick HTML5, while MediaWiki developers aren't allowed to stray a hair from Chrome's choices highly biassed, and so far rather technically unfounded.
If the fallback for logged out users is of sufficient quality, there ought to be no reason for complaints about usability. Let's maybe focus on that and move forward.
How could anything be easier to integrate than MathJax? One line in your html suffices for the simplest uses:
<script type="text/javascript" src="//cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
Yes, for Wikipedia you probably want to host the scripts yourself and do a little input checking, but how Wikipedia's MathJax support became so bloated and unmaintainable that it had to be ripped out like this is a mystery to me.
Nevertheless if KaTeX combines fast server-side rendering with high-quality textual-rather-than-image output, as its web site seems to promise, it could well also be a viable solution. It seems to be a bit more limited in what it can handle, though (see http://www.intmath.com/cg5/katex-mathjax-comparison.php for some examples of things it can't handle), so it wouldn't be a complete solution unless it improves in that respect.
I resent the "cognitive dissonance" personal attack, but I'll assume it was an accident.
But since we've strayed from the topic: One of Mediawiki's goals is to deliver content to users on many different platforms. Since Chrome is a major delivery platform, it would be unwise to refuse to support it entirely. By the same token, it would be unwise to require end users to use a browser plugin supported only in Chrome, since then Mediawiki would not be delivering content to users on Firefox, Safari, and so on. By contrast, Chrome developers feel that MathML is a minor part of their market. It makes little difference to most of their users whether or not Chrome supports MathML, so they risk little by rejecting it.
I continue to be surprised at the resistance to MathJax. It already works! However difficult it may be to integrate, it's still the easiest solution.
WOW indeed, years of bitter talks and work on MathJax... much ado about nothing? Congrats for the courage trashing years of your own work; I hope the new proposed way will achieve something.
One question on
The customization of the MathJax codebase is quite heavy.
Is that for features requested by Wikimedia users, or issues of integration? If less customization means the alternatives lack certain things which were requested in the past, we risk going through the same story again.
Ok I have submitted it https://gerrit.wikimedia.org/r/#/c/226050/ here.
This comes as quite a shock... I was so glad to get rid of those awful PNGs. But it is not much of a suprise that it was unmaintainable due to the way MathJax was integrated.
KaTeX is very promising, and we should commit to that (and preferably keep MathJax until then), but please implement it so updating requires nothing more then replacing some file(s).
@Nemo_bis the language customizations made it into MathJax and therefore to mathoid https://github.com/mathjax/MathJax/pull/1005 the customization that made client side mathjax rendering extremly hard to maintain is the rewrite of the resourceloader.
I created a ticket with regard to version number here T106414
Change 226050 had a related patch set uploaded (by Nemo bis):
Bump version to 3.0.0
https://gerrit.wikimedia.org/r/226050
Re KaTeX support: If added, this would need a fallback for the equations that KaTeX does not handle (it only supports a subset of our math markup). Since both KaTeX and the fallback would sometimes both be visible in the same articles, having the same or very similar textual appearance as KaTeX would be a priority in the fallback. But the only option for achieving the same appearance seems to be MathJax, which the developers seem intent on not supporting or including.
If we have a bug to investigate KaTeX, we can discuss the pros and cons in comparison to server-side MathJax there.
Here is another proposal: can we have MathML with fallback to MathJax? I understand the developers want MathML and the reality demands MathJax. Is there any technical obstacle to achieve this?
In general, a "fallback" is a good approach since the readers can't choose (they are not logged-in) or don't know what rendering option they should choose.
I've run Help:Formula through KaTeX. There is quite a lot missing, the biggest is lack of \operatorname. This has such extensive use throughout wikipedia that it alone rules KaTeX out.
Other things missing include \widehat, \lVert, \rVert, \imath, \jmath, \pmod, \bmod, \sqrt[n]{x}, \not \in, \not \ni, \not \equiv. \overset, \underset., \And, \implies, \iff, \P, \S.
I've just checked the Functions, symbols, special characters and not the Larger expressions with matricies etc. I ran my test a couple of months back so something might have improved since then.
Couple more missing things I noticed were \binom (and \choose but we should be using \binom instead) and \ell
As I read the comments, it seems that people have limited knowlegde & distorted information about the MathJax / KaTeX / MediaWiki / Browser developments and, sadly, know almost nothing about the technical implementation details... so I'm not sure it is very efficient to try arguing or countering the falsehoods about MathML. Instead, I'll just write one post with a few (hopefully helpful) remarks on MediaWiki math and then go back to doing more constructive work for math rendering on the Web...
@fredw: we don't have to know about Wikipedia's implementation details to know that MathSciNet, arXiv, MathOverflow etc have all been producing high-quality renderings for years using MathJax and that (for those of us not using MathML browsers) Wikipedia and the Wikipedia developers still seems stuck in the "let's just give them an image of the formula" mode that has worked so badly for so long. The format may have changed from gif to png to svg but the idea is the same.
What @DavidEppstein said...
Server-generated HTML/CSS is the way to go, whether it's MathJax or some other script. But the images will have to go.
The format may have changed from gif to png to svg but the idea is the same.
I am sorry, but unless you have technically informed comments, I would really recommend that users focus on the presented quality of the displayed formulas.
SVG is a lot more similar to MathML than it is to PNG. There is a fundamental difference between bitmap and vector graphics, and not understanding that will skew your perspective wrongly. Here is an interactive example demonstrating that SVG is a native, accessible and programmable representation of structured data:
http://tympanus.net/Tutorials/InteractiveSVG/
In fact, the ad-hoc HTML+CSS representation of mathematics and the SVG representation of mathematics are comparable entities. MathML is a step forward from each, as it captures the domain-specific peculiarities, but all 3 are variants of "formula trees" and contain comparable data payloads (although still with non-trivial differences). The opaque universe of static images is an entirely different creature, and there is no suggestion to revert to that by any of the participants in this thread.
SVG still produces \text in inappropriate fonts. It still produces images that have fonts the wrong size for the surrounding text. It still produces images with misaligned baselines. It still produce images with text that does not look as sharp as the actual article text. It still does not let you copy and paste from the middle of a formula. It still does not get colored appropriately when it is part of a link. In all of those respects it is exactly as bad as the bitmap images that we (as editors and readers rather than browser-to-server-communications-purists) have hated for so long. The only improvement of SVG over bitmaps is that if you temporarily zoom your screen differently from your preference setting it scales better. And please please stop talking as if you're moving towards MathML as a default. You're moving towards SVG as a default, with MathML as an "enhancement" for some, with its own different set of display shortcomings.
The miss match of sizes between inline math equations and surrounding text seems to be down to fonts.
Ideally the math font would have similar font-metrics. I think things look best if the x-height matches, this seems to work quite well with MathJax as the x-height of Times matches most san-serif fonts fairly well. In MathML with the MathML-fonts extension it seems to use the Latin Modern Math font. Even at the same point size the metrics of this are quite different to other fonts. Using .mwe-math-mathml-inline { font-size: larger; } seem to give roughly similar x-heights.
The SVGs produced don't use SVG's font support. Instead it converts everything to paths. I guess this makes it device independent. This may account for the heavy weight of the appearance.
You are denying that svg exhibits most of the same problems as images. That is simply false, no matter how much you want to pretend. svg is an image format (it's short for "Scalable Vector Graphics" after all). They may be vector images, but they are still images, so they exhibit all but one of the shortcomings of pngs. Their sole advantage is that they can be magnified, and that is a very, very minor advantage.
If MathML were a realistic near-term alternative to images, then I would say that it was at least worth consideration. As we've discussed before, it's not. Most users will fall back to something else. It may be the future, but it is not the present.
That leaves MathJax and KaTeX. KaTeX has enough shortcomings that it doesn't seem to be a near-term solution either. The only really strong arguments that I've heard against MathJax is that it's difficult to integrate and that it's slow. The latter is a trivial problem: It is really just a moment, and while I don't like it either, it's a problem that I and most everyone is willing to live with (witness the popularity of MathJax); furthermore, KaTeX does it faster, so it may be possible to speed MathJax. The former is not a trivial problem; I appreciate that integrating code can require dozens if not hundreds of hours of effort. Yet I suspect it would take less effort to integrate MathJax all over again than it would to bring Mathoid to the point where its output is of similarly high quality; especially since everything in Mathoid is being implemented twice, once to output MathML and once to output SVG.
@SalixAlba: Thank you for your comment.
Ideally the math font would have similar font-metrics. I think things look best if the x-height matches, this seems to work quite well with MathJax as the x-height of Times matches most san-serif fonts fairly well.
Actually client-side MathJax has some code to estimate the x-height of the surrounding text (by measuring the metrics of the 'x' character in Javascript) and then resize the text of the math. IIRC, this works well in some situations but in my experiments I often obtained a size that is too large (again, this seems to be font/browser dependent). It's probably possible to write a browser extension or do some Javascript postprocessing to mimic this behavior, but I'm afraid this would lead to performance issues.
In MathML with the MathML-fonts extension it seems to use the Latin Modern Math font. Even at the same point size the metrics of this are quite different to other fonts. Using .mwe-math-mathml-inline { font-size: larger; } seem to give roughly similar x-heights.
I think again it's font dependent, so I guess the choice of consistent text and math fonts and size adjustement should be left to the user. This can be done in the user style using standard CSS rules for registered users or using the addon https://addons.mozilla.org/en-US/firefox/addon/mathml-font-settings. Actually, starting with Gecko 41 (currently Firefox Aurora) some font configuration for mathematics will be directly integrated into the "advanced font configuration menu", similar to what we have for other languages.
As a comparison, the default in XeTeX is to use "Latin Modern Roman" for text and "Latin Modern Math" for math (see http://www.gust.org.pl/projects/e-foundry/latin-modern). You may also find a list of OpenType fonts with a MATH table in http://fred-wang.github.io/MathFonts/
The SVGs produced don't use SVG's font support. Instead it converts everything to paths. I guess this makes it device independent. This may account for the heavy weight of the appearance.
Yes, Mathoid (which is nothing more than server-side MathJax for those who missed that...) does convert everything to paths and that's obviously indeed what is causing inconsistencies with outer/inner text. I'm not sure I remember exactly what was Davide Cervone's arguments, but I suspect this interaction with outer/inner text was one issue to make possible for MathJax to generate HTML+CSS server-side. I wonder what KaTeX does here to address this issue...
What is stopping us from using MathJax to generate HTML/CSS and send that to the browser? That should be our ultimate goal; it would solve everything. The only problems I can forsee are the possible browser-specific hacks MathJax may employ (caching), and dependency on a webfont (though STIX Word is a pretty small package). However, if these can be negated, then any semi-modern browser can handle the math, and we don't need any user options or browser extensions.
What is stopping us from using MathJax to generate HTML/CSS and send that to the browser?
I admit my ignorance on this point. I don't think that will "solve everything" but at least we could replace the SVG part in the output generated by Mathoid with the HTML/CSS output. This will solve the quality complaints reported by users in favor of client-side MathJax and that will solve the problem for MediaWiki staff regarding the bad integration of client-side MathJax. As I said above, I remember Davide Cervone mentioning technical limitations for HTML/CSS conversion, but that was before KaTeX was ever invented. I suspect problems are around what is mentioned by @SalixAlba regarding knowing actual fonts used and box measurements ; and probably the unreliability of platform/browser-specific hacks for the HTML/CSS rendering (note: I'm thinking about MathJax here, I don't know KaTeX's code). So the best would be to ask the MathJax team. If they are able to implement server-side HTML/CSS conversion in their https://github.com/mathjax/MathJax-node then I believe @Physikerwelt could easily port that to Mathoid.
Anyway, since nobody seems willing to maintain a MediaWiki extension for client-side MathJax, the options for user willing to keep that rendering mode seems to be either writing/using browser extension or, for registered users, custom stylesheet/script to render the MathML output with MathJax.
First of all, I have to admit that I'm really overwelmed by the large number of responses this issue got.
@fredw: Sure. HTML/CSS output is planned for this quarter in MathJax node... but as you know things might take longer.
Furthermore, this change that has been merged only removes the outdated Wikimedia hosted MathJax clone.
Users can still use the most recent and actively maintained MathJax version provided by MathJax. Beside a browser plugin also a customized userscript is possible (cf. https://en.wikipedia.org/wiki/User:Nageh/mathJax). In that context note that there is a new mediawiki-texvc.js extension https://github.com/mathjax/MathJax/blob/master/unpacked/extensions/TeX/mediawiki-texvc.js that is now shipped with MathJax. So all Wikipedia specific \TeX macros such as \reals are supported by the MathJax versions out of the box (with the extension enabled).
@Physikerwelt. No, no. You (and also the WMF) are missing the point; this is not about the "individual" inconvenience. Personally I edit Wikipedia on my iPhone or iPad; with MathML with SVG, the math rendering is fast and looks good on my screen.
No, this is about the "readers". To repeat, other major math discussion sites or blogs use MathJax and it is reasonable that the "readers" would expect the same here. The PNG makes us look ugly and we don't like it. It's that simple.
@TakuyaMurata The point is defined by the topic of the conversation. You are talking about rendering for unregistered users. This is a seperate issue and WMF and me are aware of the PNG problem. My goal is to make MathML + SVG default as soon as there is consensus that it's better than PNG. I already have the impression that SVG + MathML produces better rendering compared to PNG. But as long as there is no consensus about that fact WMF won't enable the new rendering by default.
Some experiment has shown its pretty easy to have client side MathJax through user javascript pages. The minimal script is
window.MathJax = {
tex2jax: {
inlineMath: [ ['$','$'], ["\\(","\\)"] ]
}
};
mw.loader.load(
'https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML');I'm not sure if there is a better way to do it. I'm not quite sure how to execute a command when an external script has finished loading with the resource loader.
Adding the mediawiki-texvc.js that @Physikerwelt mentioned would add the missing commands.
It might be an idea to create a gadget for client side mathjax. This would satisfy the needed of logged in users who want the most beautiful bus.
As to making SVG+MathML the default. I'm generally fine with that, the SVG is not quite perfect but a lot better then the PNG. The only worry is that some (webkit based) browsers have had poor MathML implementations in the past. Currently they are mothballed but they could be revived at some point in the future. If this was to happen then it would be better to serve them SVG rather than MathML.
This was the only reliably working rendering service. Guess will have to look for another extension to do the Job.
Hi,
I'm part of the MathJax team.
I admit I find it somewhat difficult to join the discussion so late but I thought it might still be helpful. I apologize if I missed discussions happening elsewhere in the wiki-verse. Also, as far as I can see, people on this thread are either part of the Wikipedia math community or volunteers working on the MediaWiki math extension; WMF is missing and that seems to be a major obstacle.
$('.mwe-math-fallback-image-inline').addClass('mwe-math-mathml-a11y');
$('.mwe-math-mathml-a11y').removeClass('mwe-math-mathml-a11y');
mw.loader.load('https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=MML_HTMLorMML');seems to roughly do the trick -- though I'm not sure what those classes affect otherwise; maybe @Physikerwelt can advise. This approach could be tweaked (e.g., reduce jitter by only removing the SVGs after MathJax is done, improve loading behavior).
I realize this is off-topic but questions were raised here so I thought it's best to answer here. The problems mentioned by Wikipedians regarding Mathoid's SVG output are a mixed bag.
Some of them are unlikely to change (e.g., browsers do not allow selecting (parts of) SVGs, MathJax's SVG output uses paths), some issues could be improved (e.g., the "blurry" paths could be optimized by configuring MathJax-node differently), some are due to Mathoid's design (T106088 (SVGs lost when printing in Chrome), T89620 (text elements lost in Chrome), SVG as images don't inherit color).
Also, as mentioned, the upcoming MathJax v2.6 release will introduce a new output that generates HTML and CSS and can be pre-generated server-side (and also happens to be significantly faster on the client). But it's not clear to me if WMF would consider this an option for Wikipedia.
Finally, I realize we have a history and I don't want to start a fight. But @fredw, could you please *not* speculate about MathJax technology or opinions of MathJax team members? That can mislead people (just like inaccurate comments about Firefox MathML support can). If there's a question about how MathJax or MathJax-node works, we're happy to answer it.
Best regards,
Peter.
Given that I am the one who worked on integrating MathJax with MediaWiki's resource loader and that (contrary to you, Peter) I read & hacked the MathJax codebase, I believe you are not really fair by insinuating I do not have any legitimity to speak about MathJax technology. Also, I'm sure you know that my "speculation" about the opinions of MathJax team members are based on real comments they have made and not taken from nowhere. Certainly, technology and opinions may change, but instead of preventing people to exercise their freedom of speech, you should rather use yours to propose a different opinion or correct any mistakes. In particular please confirm or negate the opinions I credited you with, so that we can clear up any misunderstandings:
a) Server-side conversion via Mathoid is the preferred way
I got my information from @Physikerwelt (and maybe other emails I was cc'ed to). If I trust him, you have lobbied to make client-side MathJax the default a year ago. However the MathJax team is now promoting its new "MathJax-node" server-side conversion and you agreed with @Physikerwelt that the preferred way for MediaWiki was Mathoid. Last time I asked @Physikerwelt about whether you agreed with his idea of removing client-side MathJax from MediaWiki, he said that you indeed wanted to promote MathJax browser plugin instead...
b) the future is to have native MathML in browser
I think you have publicly stated that several times, so it will be easy for people to find references. The last one I saw from March: "While we are proud of our accomplishments at MathJax, we know that we can only provide half the solution: native browser support must be the goal." (http://exchanges.wiley.com/blog/2015/03/02/making-math-and-science-first-class-citizens-on-the-web/). Since some people in this thread have indicated that native MathML is not the future and that client-side MathJax must be the only real goal, I'd appreciate if you could reaffirm the position of the MathJax team here.
Thanks.
As I wrote,
If there's a question about how MathJax or MathJax-node works, we're happy to answer it.
I am on the council of the Institute of Mathematics and its Applications, the UK professional and learned society for mathematics. We are interested in using Wikimedia projects as part of our outreach, and already know that mathematics editing and rendering in Mediawiki is problematic. I would be happy to receive suggestions from the participants in this discussion as to where and how these issues might be resolved, and whether I can make a proposal to the IMA to try to support a common way forward.
Please don't pursue the debate on my email! I'm looking for suggestions as to what would help resolve these issues. Would it be a meeting, an online discussion in some other forum, a teleconference, or what? What resources might be needed to produce the solution? Who is able to contribute time, money, expertise to the solution?
There is a roadmap for Math extension development https://www.mediawiki.org/wiki/Extension:Math/Roadmap.
The last meeting https://lists.wikimedia.org/pipermail/wikitech-l/2015-May/081807.html had only few attendees and had a stronger focus on technical details w.r.t mathoid. We can organize another meeting end of septemer, I'm happy to use additional channels for announcing the meeting.
Why is SVG fallback now broken for Chrome-like browsers? (I would hope it's not removed intentionally??) Right now, everything shows up as blank squares when I choose the "MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools)" option on Chrome. Which means the alternative is either: use the archaic PNGs or install a MathJax extension (oh wait … can't do that on a smartphone).
The SVG fallback provided the best trade-off: minimal browser requirements, fast rendering, and excellent quality, a good alternative to the slow MathJax and pixelated PNGs. Personally, I also preferred its font rendering a lot more than MathJax because of its fuzziness.
Why is SVG fallback now broken for Chrome-like browsers?
This bug was about the client-side MathJax parsing & rendering. Please open a separate issue if the SVG fallback is broken in Chrome.
In reply to Fylwind I've got the same problem and created a bug T108388. Looks like things are working properly now but some pages are still failing.
I will be at the Wikipedia Science Conference in London 2-3 September and will propose an unconference slot on the question of mathematical, and if possible, other scientific, editing and rendering.
Forgive me for coming in late on the conversation, but this is a topic I care a lot about and I'm a little confused about the dichotomy between MathJax and MathML that I'm picking up on here.
If I ignore the technical implementation problems with MathJax, is there a reason we can't have MathML that is interpreted by MathJax in browsers without MathML support (as it seems like mml2jax is designed to do according to here)?
No need to go over this again here if it's been discussed elsewhere, but if that is the case I'd appreciate a link to the relevant conversation, because it seems like we could take advantage of the accessibility and speed advantages of MathML in browsers that support it while providing beautiful MathJax rendering to all other viewers like MathOverflow does.
Change 226050 merged by jenkins-bot:
Bump version to 3.0.0
https://gerrit.wikimedia.org/r/226050
I'm also a fan of MathJax over older implementation like MathML, and quick-fix implementation like KaTeX. I think that HTML/CSS rendering in MathJax is great (like the way Math Vault does it for instance). I do think that speed is generally a problem with MathJax, though that's something that can hopefully be improved in the upcoming MathJax3, which seems to be lagging behind much like the way LaTeX3 is today.
For those curious about KaTeX, you can use it with the JS below, either in common.js or from a brower userscript:
// no-semi, print-width=88, trailing-comma=all
$("<link>").appendTo("head").attr({
type: "text/css",
rel: "stylesheet",
href: "https://cdn.jsdelivr.net/npm/katex/dist/katex.min.css",
})
var css = String.raw
$("<style>").appendTo("head").text(css`
.katex-display {
margin: 0.5em 0;
}
.katex-display > .base {
margin: 0.25em 0;
}
.katex-display > .katex {
white-space: normal;
}
`)
await $.getScript("https://cdn.jsdelivr.net/npm/katex/dist/katex.min.js")
await $.getScript("https://cdn.jsdelivr.net/npm/katex/dist/contrib/mhchem.min.js")
// for text mode
function fallback(el) {
// strip away the $
return el.innerText.substring(1, el.innerText.length - 1)
}
// for "mathml with fallback" mode
function mml(el) {
return el.querySelector('semantics > annotation[encoding="application/x-tex"]')
.textContent
}
function render_tex(el, how, displayMode) {
let span = document.createElement("span")
try {
let source = how(el)
if (source.startsWith("{")) source = source.substring(1, source.length - 1)
katex.render(source, span, { displayMode, fleqn: true })
el.replaceWith(span)
} catch (e) {
console.log(el)
console.warn(e.message)
}
}
document
.querySelectorAll("span.tex.mwe-math-fallback-source-inline")
.forEach((el) => render_tex(el, fallback, false))
document
.querySelectorAll("span.tex.mwe-math-fallback-source-display")
.forEach((el) => render_tex(el, fallback, true))
document
.querySelectorAll("span.mwe-math-element")
.forEach((el) => render_tex(el, mml, false))
document
.querySelectorAll("div.mwe-math-element")
.forEach((el) => render_tex(el, mml, true))(Try the reflow. It's pretty cool.)
So how's KaTeX doing in 2021? The errors I got on the help page are:
KaTeX parse error: Limit controls must follow a math operator at position 58: …ratorname {sn} \̲l̲i̲m̲i̲t̲s̲ ̲_{b>c}(b+c)
KaTeX parse error: Undefined control sequence: \S at position 63: …Re ,\circledS ,\̲S̲ ̲,\P ,\mathrm {\…
KaTeX parse error: Undefined control sequence: \P at position 9: \amalg \̲P̲ ̲\S \%\dagger \d…
KaTeX parse error: Undefined control sequence: \sideset at position 2: \̲s̲i̲d̲e̲s̲e̲t̲ ̲{_{1}^{2}}{_{3}…
KaTeX parse error: Undefined control sequence: \iiiint at position 2: \̲i̲i̲i̲i̲n̲t̲ ̲\limits _{F}dx\…
KaTeX parse error: Undefined control sequence: \definecolor at position 2: \̲d̲e̲f̲i̲n̲e̲c̲o̲l̲o̲r̲ ̲{myorange}{rgb}…So it's much more usable than before with \operatorname being implemented, but still not quite there.