PS: Remember that when MW 1.19 went live, it caused the default option "HTML if very simple or else PNG" to be replaced by "Always render PNG", and there were complains about that because the old default was better than PNG in some sense. So this bug would be the way to "restore" the previous "better than PNG" default.

• Adding (open) bugs which are currently marked as blockers for bug 31406
• Removing "shell" keyword for now, since the blockers would need to be fixed first

I don't think that this is likely to happen in the near future. MathJax is significantly slower to render even on high end computers and would likely cause unacceptable slowness on math-intense pages for users of low-end machines.

I'm inclined to close this as WONTFIX for the time being. I'd suggest looking into ways to expose the MathJax user preference a bit more so that math-interested users can discover it more easily. For example, we could integrate the right-click menu that MathJax exposes with the PNG rendering mode.

(In reply to comment #3)

I don't think that this is likely to happen in the near future. MathJax is
significantly slower to render even on high end computers and would likely
cause unacceptable slowness on math-intense pages for users of low-end
machines.

Just to mention one of the blocker bugs, it also has no localisation (bug 35038).

I'm inclined to close this as WONTFIX for the time being. I'd suggest looking
into ways to expose the MathJax user preference a bit more so that
math-interested users can discover it more easily. For example, we could
integrate the right-click menu that MathJax exposes with the PNG rendering
mode.

Closing this per Erik (blocker bugs are easily overlooked, status is clearer to readers). Reopening is cheap when issues are solved.

So we have a problem. We need to discuss maths on our talk page. Its a central part of building the encyclopedia. Now Flow is going to be introduced for our talk pages which will not allow standard wikicode as only the VisualEditor is allowed. Hence the VE must have math support, that is Bug 43058 must be fixed.

Now a maths visual editor is a herculanean task but central to that is a render. MathJax could potentially do it, texvc cannot as you would have generate a new image on the fly with each key stroke. Any other system is just going to be an ugly kludge.

In reply to Erik's comment. You have a tradeoff between the time it take javascript to render, with the time it takes to download all the images for the equations. It can take a considerable time to download a maths heavy page like Help:Formula. I would say they just about balance each other.

physik wrote:

I think it is really important to have a stable, secure, and long term supported way of math rendering.
As I'm working on integrating LaTeXML a rendering engine that converts tex to MathML I was running into a couple of issues.
First, Wikipedia uses texvc and not tex, therefore I had to create a list of special user defined commands. MathJax has this list as well.
To my mind it's a suboptiomal solution especially with regard to long term support. I propose to come up with a grammar that can be used by a wide audience (e.g. antlr) and convert that into native php code. This grammar converts texvc to tex and eliminates all commands that are not allowed.
Second, there are some security aspects, i.e. that someone could put code that is a potential security risk for the visitors. Texvc eliminates this security risk by returning pictures only. On the other side as texvc is a potential security risk for the server, since the rendering must take place on the same machine as the core server works.
LaTeXML can use a separate server, but if there is an attack to the network the traffic could be redirected to another server. Therefore the output of LaTeXML must be checked again before returning it to the users browser.
If the users browser supports mathml only bugs in the browsers mathml implementation can be a security risk. If not MathJaX is needed to convert MathML to whatever, which comes along with all the Javascript issues.
As a result I think that it would be good to seperate the tasks somehow.
The Wikimedia Math extension php code should convert texvc to tex and ensure that only valid tex is passed to the rendering engine.
Than a standard rendering engine can be used and the final result can be validated according to standard methods. e.g. validate MathML out against the W3C MathML scheme.
In summer 2012 I proposed the LaTeXML render at CICM 2012, now it's avalible as opt-in[1].

[1] http://arxiv.org/abs/1304.5475

physik wrote:

PS: There is a demo at
http://demo.formulasearchengine.com

you can click on
http://demo.formulasearchengine.com/index.php/Special:Random

to get a random page of the english wikipedia... the pages are not cached so it might take about 20 seconds, especially if images has to be loaded from commons

@Richard, the GSoC project for a math-editor component is coming along nicely. The approach is along the lines of the wyiswhat editor http://oerpub.github.io/Aloha-Editor/. The OERpub folks have done some testing (with regular school teachers) see http://kefletcher.blogspot.com/2013/05/testing-editor-designs.html.

@Martin I think texvc's restricted TeX fits very well within the concept of Wikitext and texvc has (unfortunatly) proven to be "stable, secure and long term supported". Of course I'm biased, but I think MathJax solves the issues you describe (well except the ominous "along with all the JS issues" -- not sure what you're referring to). If all you're after is MathML and SVG output, then the MathJax-driven VE plugin could easily produce those as well.

This is getting off topic, but I would add: we need more rather than less client-side rendering of scientific content. Server side rendering is inherently static, in fact, MathML (which is really just the math equivalent of text) feels a lot like HTML 1 at this point -- barely acceptable, static rendering in the browser. E.g., mathapedia and mathbox show what the future of math on the web might be.

I think physikerwelt idea of semantic processing of mathematics is a nice idea and fit with the foundations wider goals. However it a bit off topic for this bug. I've created a new bug 51381 which the details where it can be explored in more details.

physik wrote:

(In reply to comment #9)

I think physikerwelt idea of semantic processing of mathematics is a nice
idea
and fit with the foundations wider goals. However it a bit off topic for this
bug. I've created a new bug 51381 which the details where it can be explored
in
more details.

Thanks... sorry for the off topic... if I just said use
$wgDefaultUserOptions['math'] = 7
that would be somehow pointless.
By the way 2 is html (deprecated) and mathjax is 6.

7 includes 6 since you it can be combined with MathJax (as you can see in the demo) but it must not. The advantage to use MathJax based on MathML is that it is reasonably fast. (To my mind that's not the case if you use MathJax without MathML). Furthermore you can display MathML without a need of JavaScript support.

A visual editor that is based on MathML would be easier to implement and handle than one that is based on TeX. But I would double think about doing so, since than the Tex source is gone. (OK the same holds for the visual editor in general.)

To stick to the topic, which is not visual editor:

I fully support the initiative to switch the rendering mode.
However, I think we should find a well defined process for doing so.
One opportunity could be:

1. Collect the alternatives
2. Compare and benchmark them
3. Discuss the results
4. Make a decision (Maybe even vote oOo)

This sounds a bit lengthy... but due to the fact that this bug is open for more than a year now... that might be really quick.

A first good step might be to resolve bug 48036 (opt-in for unregistered visitors). That way, people can vote with their feet.

physik wrote:

In the meantime the situation has changed. So it might be better to create a new bug instead of updating this.

What's the status of this now? It's been a while since it was last discussed. Are the reasons to not use MathJax just as valid now?

The only report currently marked as blocker is T37186 and is being discussed there. Going through the Math component may find some more blockers.

Please comment on that bug
https://phabricator.wikimedia.org/T78046