Last modified: 2014-11-17 10:35:30 UTC
From bug 31406 comment 0: > A lot of work has gone into making it possible to use MathJax to view > TeX on Wikipedia. Probably more than 20,000 article use TeX (or > whichever variant of TeX Wikipedia uses). I have corresponded with > Robert Miner, MathJax Project Director and Vice President or Research > and Development at Design Science, Inc. about the fact that MathJax > could now be used. I told him that possibly in coming months MathJax > would be adopted as the default means of viewing TeX on Wikipedia. As I understand it, Michael Hardy was proposing MathJax as the **default** math mode, but since setting $wgMathUseMathJax = true on Wikimedia wikis doesn't imply that it would be the default mode, I'm opening this bug to track what still needs to be done. This will also helps to separate the blockers of a "experimental deployment" (which is already done) and the blockers of a "full deployment" of MathJax on WMF wikis. If I understood it correctly, this would be the new setting: $wgDefaultUserOptions['math'] = 2; Fell free to move some blockers/dependencies from bug 31406 to this one as needed.
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.
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
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.
(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.
In the meantime the situation has changed. So it might be better to create a new bug instead of updating this.
