Feedback on Google Charts for TeX processing

Question

We have implemented google charts TeX processing based on John Gietzen's grease monkey script which from our perspective works pretty well. There are a few advantages to using google charts:

1. They pay the bandwidth and CPU costs of generating these images
2. They are very fast which keeps with our motto that "Speed is a feature"
3. They are google and can scale

What I need to know are the cons - we are looking at implementing MathJax as a client side library based on Anton's suggestion but are hesitant based on the size of the dependency and speed of page rendering.

Is the google charts solution good enough or are there too many edge cases that make another library much more appealing?

Edit:

I'm getting a general impression that MathJax even though it may have issues with speed and has a heavier distribution dependency - it is worth serving instead of google charts. Thanks for the feedback everyone, expect some positive changes in the following day or two.

Edit: We have implemented MathJax on this site as well as the main Math site. This release of mathjax is currently in beta however once it is release we will update the library here.

Please keep contributing feedback so we can continue to make improvements.

Answer 1

The Google Charts solution was only good enough when it was a user-provided work-around. Google Charts only renders a limited subset of LaTeX, in particular missing commonly-used things like binomial coefficients, and it chokes when the input (or maybe the constructed output) is longer than some particular length.

There are some other similar online-rendering solutions (e.g., http://www.codecogs.com/latex/eqneditor.php), but it seems to me that MathJax is the most likely to work on the largest subset of LaTeX and it does not depend on an external service. Also, the client-side rendering makes toggling between rendered and un-rendered forms possible, as on MathOverflow.

Answer 2

One issue with the current implementation is that it's acting even in places where it shouldn't, such as within code environments that are "displayed", not "inline": consider this Perl script full of dollar signs, on the TeX StackExchange. This is probably relatively easy to fix.

Actual issues deciding between Google Charts and MathJax are:

• Google Charts supports a much smaller subset of TeX syntax, and breaks more easily (sometimes because the TeX has to be passed in the http request, and it tends to choke)

• I think Google Charts needs everything to be on one line. (Haven't checked this.)

• With jsMath/MathJax at least, the TeX is rendered even in Preview, not just in the final page. Being not able to see the results when you type them will invariably make it necessary to go back and edit often.

• The Google Charts results are ugly: everything is oversized or vertically displaced, so it's not at the same level as the rest of the sentence

• MathJax can be set (on the client side) to produce either MathML or TeX, and the former seems to render faster: this page renders slightly more quickly than this page. Speed will improve, for instance jsMath seems faster.

• jsMath has this nice feature where you can double-click on a TeX expression and see its source, which is useful sometimes, e.g. if you want to copy something mentioned in the question or another answer. MathJax can also do it with right-click, 'Show Source'. With Google Charts, it's much harder to see the source behind the image.

• Apparently, MathJax is accessible to, say, blind users (and everyone benefits from being able to scale images if they want).

Answer 3

Google charts renders everything in a single size: effing huge. Unlike real LaTeX, or indeed MathJax or jsMath, there is no attempt to kern the characters correctly or adjust heights, etc. to make things look nice. You should seriously consider Anton's suggestion. He did a lot of research before picking the TeX renderer for MO (and then further research on MathJax when it was announced), and I trust his opinion on this matter.

Here's an example of how terrible it looks.

Answer 4

Thanks for implementing MathJax!

The #content div has the overflow-x:hidden property set, but that plays slightly badly with long equations which are simply cut. Removing that property seems not to break anything and results in a horizontal scrollbar to show up when it is needed (it is a bit not traditional to have it appear there, but well...)

See How to solve a cyclic quintic in radicals? for an example of a looooong equation. The only way to look at it in all its glory is to remove the overflow-x property.

Answer 5

While the speed of MathJax is indeed an issue (although it is expected to become better with time...), having correct, more or less general, and beautiful formulas in the page is way more important.

I wonder if Google could be convinced to host MathJax...

Answer 6

Not totally Google-charts related, but those <img>s should have vertical-align: middle; set to the CSS. It is currently set to baseline which is too low.

Consider: $\frac12 + \frac13 = \frac56$.

Of course, this is not going to solve more complicated alignments
like $1 + \frac 1 {1 + \frac 1 {1 + \frac 1 {1 + \frac 1 {1 + \dotsb}}}}$ and $x^{x^{x^{x^{x^{x^{x^{x^\ldots}}}}}}} = 2$ (these are supported by MathJax).

Answer 7

Well I'm having the issue that it does not work in IE8. Have tried tweaking every setting that it might have a chance to affect the image displaying and none has worked.