10
$\begingroup$

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.

$\endgroup$
2
  • 3
    $\begingroup$ Thanks for soliciting and responding quickly to feedback... much appreciated! $\endgroup$
    – ShreevatsaR
    Jul 30, 2010 at 6:17
  • 3
    $\begingroup$ Geoff, by the way, according to our tests on MO, it's worth it to force HTML+CSS output for MathJax at the moment, since the mathML output is currently slower and looks worse. Also, even if you decide not to do the above for all browsers, please do it for Opera, at least. Opera's mathML support is dismal at best, but it still flags itself as mathML compatible. At the moment, mathJax lacks a user control panel and therefore does not allow the user to choose to use mathML or not. $\endgroup$
    – 97832123
    Jul 30, 2010 at 8:03

7 Answers 7

Reset to default
10
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ Binomial coefficients was a big thing for me when translating some of my notes for courses to Google Docs for easy searching. $\endgroup$
    – Thomas Owens
    Jul 29, 2010 at 22:50
  • 1
    $\begingroup$ I agree. MathJax and jsMath look much better than the Google solution. $\endgroup$
    – Sophie Alpert
    Jul 30, 2010 at 1:19
6
$\begingroup$

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).

$\endgroup$
1
  • $\begingroup$ We have removed TeX processing from tex.stackexchange.com for now. Most of the time the community is talking about code to use TeX, therefore I have removed this component. $\endgroup$
    – Geoff Dalgas
    Jul 30, 2010 at 5:22
4
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ Try changing your double $'s to singles with a \displaymath. $\endgroup$
    – Larry Wang
    Jul 30, 2010 at 1:20
  • 1
    $\begingroup$ I refuse. When a proper system is put in place, it will render correctly... $\endgroup$
    – 97832123
    Jul 30, 2010 at 1:34
4
$\begingroup$

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.

$\endgroup$
1
  • 1
    $\begingroup$ I can see it fine in Chrome by clicking and dragging, but I agree that this isn't ideal. $\endgroup$
    – Qiaochu Yuan
    Aug 3, 2010 at 3:27
2
$\begingroup$

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...

$\endgroup$
2
$\begingroup$

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).

$\endgroup$
2
$\begingroup$

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.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .