Possible Duplicate:
Can we turn off math-tex please?
Why doesn't maths render as maths?

... but, until we get it, I have created a GreaseMonkey script for use here.


To use the script, simply enclose the markup in dollar signs like so:


The script has some severe limitations in that it does not do recursive decent parsing. As such, it cannot handle this format:

$ \text{ $content$ } $

This is primarily of use for math markup, but will work for anything supported by these seven rendering services:


marked as duplicate by doncherry, diabonas, Martin Scharrer Mar 22 '12 at 20:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

can you write something here as an example for its use (so we can see it's working)? –  Amir Rachum Jul 26 '10 at 19:58
Whoops - I clicked on the wrong duplicate. Sorry. –  Loop Space Mar 17 '12 at 19:03

7 Answers 7

Why do we need TeX markup?

Firstly, what is usually meant by this is "We need TeX mathematics markup" rather than the full power of TeX. That's subtly different.

Secondly, what benefit would that bring to this site? I can't actually think of one, but I can think of several reasons why it would be a bad thing:

  1. It might interfere with quoting TeX markup that is meant to be left alone (it can quickly get annoying to have to put every TeX command in backticks)
  2. Whatever method is used, it is likely to have its own idiosyncrasies and so it could become hard to distinguish errors due to TeX from errors due to the conversion method
  3. If people need to show something that's compiled to demonstrate an error, then they should link to a PDF where they can be absolutely sure that what everyone else is seeing is what they mean them to see

(For comments on actually implementing this, see my comments to this question on the main site.)

Even PDFs don't necessarily display the same on every computer. We'd have to go with images. The crappy part about having uploads is, of course, that nobody who has these problems has a viable long-term hosting solution. –  John Gietzen Jul 27 '10 at 12:01
Well, the best method is to include a minimum code model in the question for anyone to cut-and-paste and try out for themselves. For this reason, I wouldn't like any sort of "preview" on the site itself, either via linking to images or pdfs or converting to XHTML. (Of course, images don't display the same everywhere either!) –  Loop Space Jul 27 '10 at 12:11
@Andrew: TeX markup would be useful, for illustrative purposes if nothing else. (Take this question as an example: tex.stackexchange.com/questions/312/… ). It's nice to be able to show what a snippet of TeX code looks like. But of course, it must not interfere with the much more common scenario of displaying TeX markup, but that could be as simple as not TeXifying markup inside code regions (like here) –  jalf Aug 6 '10 at 11:41
@jaif: I can see the use in having a real TeX renderer (ie not some javascript make-do) so that we can see what code is meant to do without having to upload images to some server. I would make it separate from the question/answer box since ensuring that there is no conflict between the markdown parser and the TeX renderer would be a bit tricky, and I would make it so that someone has to explicitly mark up a region for texing. –  Loop Space Aug 6 '10 at 13:04
Downvoted; for the reasons mentioned by others, even an imperfect renderer is better than none. There are tons of questions about small, specific aspects of TeX that would already benefit from an approximate renderer for math only, as on the Math Overflow SE. I think this is one of the two features that this site really needs (the other being TeX syntax highlighting). Everything else is fluff. –  Konrad Rudolph Oct 17 '10 at 14:49
@Konrad: I strongly disagree with the phrase "even an imperfect renderer is better than none" for the first reason given in my second answer to this question. Indeed, my two answers should be read in chronological order not vote order. –  Loop Space Oct 18 '10 at 7:57
@Andrew: Well, see my own answer for example posts where an approximate renderer would suffice. Furthermore, see John’s comment above – even a real TeX renderer may actually produce slightly different output depending on the driver, the program used to display/print the PDF etc. I agree that a real TeX renderer would be vastly superior (and even then some cases may still necessitate uploading the actual document or a screenshot) but if we can’t get one that shouldn’t be a show-stopper. To address your specific point: of course that could be a problem but I doubt that it will be in practice. –  Konrad Rudolph Oct 18 '10 at 8:25
(cont’d) We don’t have to rely on the SE TeX renderer alone, we always can cross-check with a local rendering, so any artifacts in the rendering will be spotted easily. –  Konrad Rudolph Oct 18 '10 at 8:27
But then I'd rather have it off by default and a side-box saying "Click here to get an approximate rendering of the code". If it's on by default, people are going to assume that it's accurate even with a big flashing neon sign saying otherwise. Also, such things slow the system down incredibly so I'd like to only have a rendering rendered if I specifically ask for it. –  Loop Space Oct 18 '10 at 10:33

Having now used the site a little, I can see that there is a case to be made for a way to included rendered TeX. I would argue that:

  1. It has to be true TeX. Otherwise, we can't be sure that what we're seeing isn't some artifice of the method used to render it.
  2. It has to be explicitly selected for. Otherwise, it's confusing for newcomers to have their code suddenly converted.
  3. It has to be easy to separate from the Markdown markup. Otherwise, it gets confusing remembering what needs to be escaped and what not.

So here's a suggestion: a web-server that has a standard installation of TeXLive 2009 that can call tex, or one of its variants, on files uploaded. Somewhat similar to that done at the arXiv. But to encourage people to provide minimum working examples, there should be a quite low limit on file size. I would consider putting a limit on the number of pages rendered, perhaps 2 as sometimes issues are about differences between one page and another.

I would then have the server cache the result, either as a PNG (if small enough) and/or a PDF, and return a link to that cache, maybe using md5sum or something to generate a unique URL that isn't too bad. This could then be included back in the question/answer using the usual Markdown image syntax.

As well as a file upload method, there could be a short-cut whereby the contents of a textbox gets processed inside some standard setup.

This is similar to my suggestion here: meta.tex.stackexchange.com/questions/158/latex-sand-box/206#206 –  Yossi Farjoun Aug 6 '10 at 13:55
You'll have all kinds of security problems if you let people upload arbitrary TeX file and blindly run tex on them. –  Jukka Suomela Aug 6 '10 at 19:32
@Yossi Farjoun: Yes, it is pretty similar. @Jukka Suomela: the arXiv manages it fairly well. I'd be surprised to learn that it couldn't be done with a fairly simple configuration. One could always add an openid authentication step, I guess. –  Loop Space Aug 6 '10 at 20:06
@Jukka: with write18 disabled, I think that *TeX are pretty much sandboxed. Am I mistaken? Limit the output file to 2-10 pages and 5mg, limit the input size to 100K...anything else? –  Yossi Farjoun Aug 7 '10 at 11:21
I can provide a server for caching if this is a problem... –  Yossi Farjoun Aug 7 '10 at 11:23
Something that could be looked at is the Common LaTeX Service Interface CLSI. It provides an interface to submit TeX jobs to a server and receive the results. It powers ScribTeX and LaTeX Lab. –  Sharpie Aug 10 '10 at 8:47
@Yossi: It is also important to make sure TeX is configured such that it will refuse to write to important files. (That is, assuming there are any such files that it would be able to write to in the first place...) –  SamB Nov 30 '10 at 0:18
@JukkaSuomela: Only if you don't use ulimit and chroot etc. –  Martin Schröder Nov 17 '11 at 18:55
In the time since this was written I cannot think of a single question or answer where I have wished for TeX rendering on the site. I shan't change this answer (since that would invalidate the votes) but let it be recorded that I no longer even agree with this type of rendering being made available. –  Loop Space Nov 8 '12 at 13:42

The problem with every solution other than server-side TeX rendering is: this is a site about TeX and friends and examples should be generated by TeX and friends.

However, there is a slight problem: it's not only about equations, which can be rendered without a hinch as images. Most problems people have are those of positioning. That actually means that every example marked as "complete" in some way (i.e. not an excerpt) should be rendered on server to some sensible format, stored on some statically-deployable subdomain and made available in at least two formats: original rendering and a PNG thumbnail, the latter being a reduced rendering of a complete page in output format.

Implementing this stuff would probably begin with an installation of current TeXlive on some server. Each user should be able to mark some code as "to be rendered" and probably also specify the engine (ConTeXt, LaTeX, XeLaTeX, etc.) The following edge cases should be considered though:

  1. "My DVI is broken but PDF using pdflatex is ok"
  2. "This code used to work with MikTex version X, but doesn't on TeXlive 2009"

The easiest would probably be to go with the 80/20 rule and exclude such questions from being rendered.

Well, I think case #1 (or wanting help with a document that will only work with one or the other mode) is common enough that it would be reasonable to support both the DVI- and PDF- output modes of whatever TeX engine(s) is/are provided. –  SamB Nov 30 '10 at 0:24

I fee that this is a pretty important feature for the site, which is why I’m pushing the discussion.

While Andrew’s request would be the ideal, I believe that even an approximation would help a lot (and is more realistic to get). I’d like to point out that two of the potential problems he pointed out are trivial to solve:

Markdown can easily be extended to generate some kind of “TeX environment”, like the current code environment. There are tons of possibilities, the simplest being a dedicated <tex> pseudo-HTML tag. This would be completely unambiguous.

Here are a few posts that would benefit from some kind of rendering, just on the current top page of questions:

Indeed, most of my own posts contain images of rendered LaTeX which are hosted off-site and might accidentally be taken offline by me in the future (I’m sloppy with my web resources). (Issue fixed.)

Note that SE now hosts images. If you click on the "image" button in the editor then it asks you for a file to upload, so the "off-site" issue is now solved. –  Loop Space Oct 18 '10 at 9:14

The #latex channel on irc.freenode.net has tex, latex and context bots which can generate pngs and svgs. I would be great when explaining and showing the differences between suggested approaches, as sometimes it is very subtle and not obvious from the markup.

E.g. explaing \phantom is best with two small samples/images then by saying ``it's like invisible ink"


The problem with this is that people using other browsers (like IE or Safari) see what looks like line-noise (although raw TeX markup is more acceptable on this Stack Exchange than on others). A better solution may be to use a service that compiles the equation to PNG and then host it using a service like TinyPic.

I put together a list of such compilation services on the statistical analysis stack exchange.

This way everyone gets to see what the equation looks like.

IE has an extension called GM4IE that should be able to successfully run this script. (Minus the settings and menu.) –  John Gietzen Jul 26 '10 at 20:23
Having to use external services seems incredibly tedious to me. –  Daniel Egeberg Jul 26 '10 at 20:25
In my opinion having to set up a browser plugin would be equally tedious for newcomers who are trying to learn LaTeX. It may even reinforce conceptions that "TeX is too complicated". Of course, the real solution is to get LaTeX support baked into the Stack Exchange engine. –  Sharpie Jul 26 '10 at 20:29
@Sharpie: Of course, that is the answer. However, what do we do in the meantime? –  John Gietzen Jul 26 '10 at 20:36
Well, my suggestion is to take an approach that will make output immediately accessible to the most people. Unfortunately, this requires more effort on the part of people writing posts- but decreases the effort for a far greater number of people who will read those posts. I definitely don't mean to belittle the effort you put into your script (I use Chrome myself)- but unfortunately cross-browser support is a thorny issue. –  Sharpie Jul 26 '10 at 20:42
Well, the problem that I have with that, is: when we finally do get support, our old posts won't "light up" like they should... –  John Gietzen Jul 26 '10 at 20:49
@Sharpie: Things like jsMath just require Javascript, which hardly counts as a browser plugin. –  Daniel Egeberg Jul 26 '10 at 20:54
@Daniel Egeberg: I think Sharpie also agrees that we need something like jsMath, and "The problem with this" refers to the greasemonkey script mentioned in the question rather than the question itself. –  ShreevatsaR Jul 26 '10 at 20:58
@John: Old posts won't "light up" because they will have been displayed correctly (albeit in image form) all along... –  Larry Wang Jul 26 '10 at 21:18
@Daniel @Shreeva: I do think things like jsMath are a good solution- a link to the script is embedded as part of the HTML sent from the server and so will be enabled without any effort on the part of users. What I am questioning is using methods that require the user to take action by installing plugins- some of which may not be available on all browsers. –  Sharpie Jul 26 '10 at 22:16

Well, I would argue about this.

  1. Every code has to be debugged, which means that it is processed multiple times giving completely unnecessary load of the server.

  2. As well, as mentioned by others, there will arise bugs of this system and questions on TeX.SX concerning only this system, which makes it real pain in the ass and kills the whole idea of this site as a "TeX wiki".

  3. I believe that what we really need is

    • a good image storage (possibly like 10 images per user up to some reputation, then enlarging the number, or similar solution);
    • with automatic file.pdf->cropped_file.pdf->file.png (the middle part optional) conversion so that you can include "PDF" images and be happy;
    • these two feature would enable to quickly include any rendered material (equation, table, symbol, page), yet being sufficiently independent of any TeX-related problems on the server side.
That's pretty much what we have through StackExchange's agreement with imgur. The storage is unlimited once you have 10 reputation, and it can take PDF (though it doesn't crop it). To use it, click on the funny blue box in the editor toolbox when writing a question or answer. –  Loop Space Feb 8 '12 at 14:14
@AndrewStacey Ok, problem solved then in my opinion. –  tohecz Feb 8 '12 at 14:55

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