Preview and posting don't match: underscores and asterisks in preview math mode aren't escaped so don't render correctly. However, when posted then they do work.

In the correct LaTeX syntax for beginning and ending maths and display maths, the backslashes need to be escaped otherwise Markdown swallows them.

(I tested this out with an answer at the "How do I display mathematics" question. I hope that that was acceptable. I've left it up so that you can see what I tried, but feel free to delete it if you think it should be deleted.)

I suspect that this is the same as the fact that parentheses get swallowed. Markdown views certain characters as special and so to produce them you have to escape them, with backslashes. As Markdown gets to the information first, it interprets things like \{ as an escaped { so strips off the backslash thinking that you just wanted to produce {. The solution is to escape the backslash: thus \\{ works. This doesn't happen with ordinary commands, like \sum because "s" isn't a special character for Markdown so it knows that you didn't want to escape it.

Markdown ought to be told to ignore stuff between mathematical markers, but I suspect that that's too deep for our esteemed hosts to hack.

Jose Capco comments

I actually disapprove with jsmath. It is by no mean browser standard, so you need most of the time to install the jsmath fonts (for the time being not even mathml is browser standard). It loads awfully slow for a page.You can only visit planetmath to know how bad jsmath can be, sure people who live in the US can't feel the effect but people in other countries with lower bandwith and slower connection to mathoverflow.net suddenly don't enjoy visiting the site. That's why I hardly visit planetmath.org the site there has some issues loading.

Can somebody explain to me why bandwidth becomes a problem? All the rendering is done on the client side by javascript, and the js files themselves are heavily cached. The only thing I can think of is that maybe the image fonts aren't cached, which seems unlikely, and certainly isn't a problem if you install the fonts (which is really painless to do). So where does connection speed become an issue?

@Andrew regarding things that don't work in the preview, but do work when posted: this is actually a bug with the Markdown preview, so we have no hope of fixing it. If you take jsMath out of the picture by not using any dollar signs, the input "\sum_n a_n" produces the preview "\sumn an", but the implementation of markdown used by the server produces "\sum_n a_n".

The boxes containing the symbols are sometimes larger than expected, which prevents you from clicking on links just under the math. For example, I made the following test post

The blue box doesn't actually appear (I put it there using the chrome element inspector). The upshot is that you can't click on any of the links that are under the blue box. So if I wanted to edit the post, I couldn't click "edit", I had to actually type the edit URL into my browser (http://mathoverflow.net/posts/4387/edit), and when I wanted to delete the post, I could only click on the late "e" in the word delete.

@David Speyer: Remember that this is coming from a bug in the markdown preview. To understand your bug, you have to get an idea of what the server side markdown implementation is thinking.

When you type something like $f_n+g_n$, the preview markdown implementation says to itself "things between underscores should be italicized", so it converts it to $f<em>n+g</em>n$. Then when you click the "preview math" button, jsMath looks at $f<em>n+g</em>n$ and says, "there's nothing for me to do here". But when you actually submit the post, the server side markdown says "those are intra-word underscores, so I'm going to leave them alone". Then jsMath finds $f_n+g_n$, which it converts properly.

The problem is that the underscores in $f'_n=f_{n-1}$ don't look sufficiently intra-word to the server side markdown, so it converts the text in between to italics, so jsMath never sees any underscores. One solution is to explicitly tell markdown to leave the underscores alone by escaping them (which I did in your post). Given inputs like $f\_n+g\_n$ or $f'\_n=f\_{n-1}$, both the preview markdown and the server side markdown will leave the underscores for jsMath to process.

@Andrew: Since we don't have access to the server at Fog Creek, we put all the jsMath material on latex.mathoverflow.net (which is an alias for latex.tqft.net, which is running on Scott's dreamhost server). We were worried about exactly the error that you got, but it didn't seem to come up. We thought that similarity of "mathoverflow.net" and "latex.mathoverflow.net" was enough to make jsMath happy. Was this a sporadic error, or can you get it consistently?

I've submitted a patch for the preview bug at meta.SE. Hopefully, they'll incorporate it into the next beta. It doesn't fix all the differences between the preview and the final output, but I think it takes care of most of them. If Fog Creek tells us exactly what the rules for intra-word emphasis are, then it probably would be very easy to patch it completely.

+1 for no jsMath on the question list.

When is it "worth it" to use the jsMath functionality? For example, if I'm typing a question or answer, it's about the same amount of work to type $\mathbb Z$ as it is to type &#8484;. The former takes a split second to render when you load the page, but looks a bit nicer. Also, if I use the former for everything, the font style for the object is consistent throughout the post. What do other people think about this?

I'm sort of leaning towards using html symbols whenever possible.

@David: that's a really hard thing to reproduce! You need to tell us the width of your browser window as well, and which font you're using, and ...

Another hiccup related to the interaction between Markdown and jsMath is that curly braces are special characters in Markdown for some reason. This means that if you type "\{", you get "{", so if you want to type something like "\left\{", you should really type "\left\\{" to escape the backslash (which would otherwise be escaping the {).

I've confirmed a bug cdouglas reported on the other LaTeX thread. I've also changed the names of the threads, so hopefully it's clear that this thread is for jsMath bugs and the other one is for the LaTeX sidebar.

In chrome on linux, this question looks like this:

But in firefox, the same question looks like this:

Edit: only recently did I realize that when this bug happens, the math really does overflow. Perhaps I should try to argue that it's not a bug at all, but an elaborate joke.

It seems like the jsMath extensions I'm loading don't include support for \mathfrak. Does anybody know which jsMath extension includes \mathfrak support?

Thanks for pointing that out. I've updated the FAQ. If there's something I should change or that I can clarify, please let me know.

Regarding the FAQ, I see a typo: "most of time time" should read "most of the time". Also, in the example regarding a_n = b_n, it would be clearer to say "the final output looks like" and then display the equation with the n's correctly subscripted, not to say "the final output looks like a_n = b_n".

Ah, okay. The fact that you had a proposed patch led me to believe that you had been able to implement it.

This is probably more than you want to do, but I wonder if it's possible for a later javascript function to overwrite an earlier one, then you could redefine the markdown call along the lines of:

function orig_markdown = markdown
function markdown = {
  do_pre_processing
  orig_markdown
  do_post_processing
}

How much should we be willing to lock ourselves into jsMath? For the most part, we're safe so long as any new mathematical markup system replaces things between dollar signs with rendered math, but there are a few places where we're really using the fact that jsMath does it's thing after Markdown. For example, in one post the raw input contains "$f'\_n=g\_{n-1}$". The extra backslashes are there so that the output of Markdown is "$f_n=g_{n-1}$, so that jsMath produces the right thing. If a LaTeX emulator got the input before Markdown, it would produce the output "f_n=g_n-1$", which is not the desired output.

If the opportunity comes along to do mathematical markup processing before Markdown processing, I think we should take it. So we should be on the lookout for things that could go wrong when we do that. So far, that's the only one I've found.

I just used the code

**Edit:**

in a comment. In the preview it came up as *Edit:* but in the final rendering it was correctly interpreted as Edit:

Andrew is right. You shouldn't complain about my modified wmd.js on meta.SE. The ** problem shows up because the modified script checks to see what the character before/after the * is. So if the ** is at the beginning or end of the line, it gets it wrong.

If you know javascript and want to help make wmd.js a more accurate preview, have a look at my patch. You can download a page to your computer and play with wmd.js locally. To see how it compares to the server side implementation, feel free to experiment at faketestsite.stackexchange.com. If you feel like you've made a version of wmd.js that is better than the one I've got now (meaning that it more faithfully previews what the server is actually going to do), please send it to me.

Greg Kuperberg pointed out a nice way to handle math containing troublesome underscores: put backticks around it. That way, Markdown interprets it as code, so it leaves the underscores alone.