• ## Discussion Feed

Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.

1.
Please report bugs or feature requests for mathoverflow's recent jsMath support here.

Known issue: after you add a comment, LaTeX in comments doesn't render. This is because at present we only do a single rendering pass, so any page content that is dynamically generated later won't be rendered.

Known issue: we don't render the LaTeX in the preview box as you type a question or answer. This is top of the todo list.
2.
If you attempt to use an align environment (probably discouraged!) with a newline, you'll discover that you need to escape the \s. That is, to make a new line you need 4: \\\\, not just 2.
3.

Sometimes, jsMath either doesn't know the size of the things it renders, or it won't put a line break in a formula:

4.

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

• CommentAuthorJose Brox
• CommentTimeNov 6th 2009

Hi!

It seems like the usual convention to write brackets for sets in LaTeX is not working properly in jsMath:

$\{a,b\}$

shows as

a,b

(i.e., just like if we wrote ${a,b}$ instead).

In other words, jsMath seems not to recognize the bar "\" before the brackets.
5.

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.

6.

Another ones that doesn't get through: \!. Of course, I use that all the time.

7.

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?

8.

Incidentally, I'm not sure if it's jsMath or something else, but it's quite ironic that the question that got this response from Scott Morrison:

congratulations on posting the first question with embedded LaTeX!

Now looks like this

9.

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

10.
I just TeXified an old answer of mine: http://mathoverflow.net/questions/3339/properly-interpreting-pi0-in-the-homotopy-exact-sequence/3349#3349

The posted answer looks fine, but the preview version is terrible. It appears that jsmath isn't correctly computing the $-boundaries, so some math code is not Texified, and some plain text is processed as math. I tried to escape all suspicious characters, as per Andrews comment above, but I figure out how to do it to make things appear correctly. 11. 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. 12. @Anton: Okay, I see. Might be worth highlighting that on the jsMath page (or the FAQ) since if someone tries hard to get their maths to look right using the preview and then posts, they may end up with something looking not what they wanted. 13. For some reason,$f'_n = f_{n-1}$doesn't render correctly. I have tried removing various aspects of the equation to make a simpler counter-example, but then it works. 14. Just got the following error message: jsMath can't load one of its required components, because jsMath was not obtained from a server that is in the same domain as the page that loaded it. 15. @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? 16. That's the first time I've encountered that error. I'll let you know if I see it again. 17. 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. 18. Not so much a bug, as just a remark. I would actually like jsMath turned off on the question list page. It's useful when looking at a specific question but I find that it doesn't add anything when looking at the questions in a list (in particular, it doesn't change whether or not I decide to look at a question) and the slowdown in page load is significant enough that it is irritating. 19. +1 for no jsMath on the question list. 20. @Andrew and @Ilya: That sounds fine to me. Are you talking about the home page (where you only see the titles) or the questions page (where you see the first two lines of the question) or both? I assume it's enough to just not execute jsMath.Process (the function that does all the work) when you're on the home/questions page. How can I tell in javascript whether you're looking at the home/questions page? If you're just talking about the home page, by the way, we can just make it a community standard not to use any mathematical markup in titles. 21. 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. 22. @Anton, here are my personal feelings about jsMath usage. There's always a tradeoff between something beautiful and perfect and something fast and dirty. In the list of questions (I'm mostly using the ones that have only titles) I would go for something "fast and dirty", since the main purpose of this list is to enlighten my interest and make me perform the initial triage. I don't have to understand the question completely, only its general topic and so the symbols don't have to be nice. Providing a correct TeX expression isn't that important in that case. The current existence of jsMath there means that the page not only takes an extra second to load, it also can also undergo a visual change after that second. I think that's too big a cost for something with a small benefit. Any new person visiting the site, additionally, has to load jsMath. I would rather push this process away from the first page. The first page just took me >10 seconds to load on a test with different browser and at least half of this time was coming from loading JS from latex.mathoverflow.com. The community consensus of not using TeX in the titles would not solve the last problem. Technically, it should be possible to to simply stop emitting jsMath's <SCRIPT> tags at the end of the page on question lists. On the other hand, when asking/answering the question the exact mathematics markup matters. It might take me 10 minutes to answer the question, so I don't mind an extra couple of seconds loading if that will help me to get it right. As you correctly say, using both LaTeX and HTML symbols makes people pay (admittedly, small) price of inconsistency. I personally would prefer to wait a bit more split seconds. So, I would encourage people to write as much LaTeX as possible, perhaps with an exception to questions where you can get by with HTML symbols everywhere. 23. I just did a test with Safari 4/Mac using Shift-Reload, which should bypass both local cache and proxies. The results: Total time: 30 seconds Load sequence (I've selected the resources that seem to load one after another): * HTML 5s * master.js 15s * jsMath.js 8.5s Another test using university's VPN: * HTML/CSS/JS 10s * various jsmath 5s * theme.favicon 2s (this kind of sounds ridiculous) Total: 18s. 24. My proposal would be to turn off jsMath on everything except where I am looking at a specific question. So both the lists and the two-line summaries. Incidentally, I find the HTML entities much nicer to look at than what jsMath renders. I find that quite ugly. But I'd rather have that than no mathematical rendition so I'm not complaining about it - just responding to Anton's remark. 25. @Anton. You should be able to look at the string document.href to decide where on the site you are. It sounds like just loading jsMath is slow and frustrating, so we should work out how to conditionally load, as well as conditionally process. 26. When a jsmath equation overflows the right margin, there is often a large blank space at the beginning of the next line. See, for example, my answer here. http://mathoverflow.net/questions/4597/inverting-ramanujans-partition-function-pn/4632#4632 I'm using Safari 4.0.3 27. @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 ... 28. If jsMath is kept on on the summary pages (which I vote against anyway) then there's a question of where the break should occur. At the moment, it can occur in the middle of mathematics meaning that that section of maths doesn't get processed by jsMath. 29. 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 {). 30. I've made it so that jsMath doesn't load unless the url matches of of the following regular expressions: regex1 = /http:\/\/mathoverflow\.net\/questions\/\d+/; regex2 = /http:\/\/mathoverflow\.net\/posts\/\d+\/edit/; regex3 = /http:\/\/mathoverflow\.net\/revisions\/\d+\/list/; regex4 = /http:\/\/mathoverflow\.net\/questions\/ask/; regex5 = /http:\/\/mathoverflow\.net\/faq/; Please let me know if this improves your experience on the summary pages, and if there are any other pages where jsMath should be loading. For debugging purposes, when the jsMath scripts are loaded, the page should say "including jsMath scripts" at the very bottom of the footer. 31. 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. 32. @Anton, this should be exactly the Safari 4.0.3 bug David talks about. I get it too, a lot. This is not surprising: Chrome and Safari use the same open-source rendering engine, Webkit. Update: bug confirmed for today's nightly build of Webkit. 33. It seems like the jsMath extensions I'm loading don't include support for \mathfrak. Does anybody know which jsMath extension includes \mathfrak support? 34. Incidentally, the FAQ entry on mathematics is a little out of date (but then it just called me a "buzzard" so I'm not sure it's really in the same universe as me). 35. 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. 36. I had an idea about a stop-gap fix for the preview since you seem to have access to the javascript. I put the details on the relevant question over at meta.SE (I think it was) which you presumably get notified about anyway... 37. 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". 38. @Andrew: (repeating my comment from meta.SE) I can stick javascript in the html fields I have access to, which is enough to run jsMath and to add the "Preview Math" button (using appendChild on the relevant div), but I don't actually have control of wmd.js, the script that handles the preview. If we want to patch it, all we can do is give the patch to Fog Creek and hope they like it enough to implement it. @David: Right, I'll edit the FAQ later today. In the a_n=b_n example, it should say something like "the final output of Markdown is a_n=b_n. If that is between dollar signs, jsMath converts it to a<sub>n</sub>=b<sub>n</sub>" (please parse the html tags yourself in that last part ... in the FAQ, it will just be the actual result of jsMath). 39. 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 }  40. I hadn't thought of that possibility. I've run some experiments on faketestsite.stackexchange.com (a sandbox I made which will disappear as soon as Fog Creek starts charging). Since the functions I want to redefine are private (start with an underscore), it looks like there's no way to access them from outside of wmd.js. But if I just replace all of wmd.js, I can make the desired modifications. I really don't like this solution, but the preview bug is annoying enough to me that I'm going to do it (in about an hour or so, after a bit more experimentation). Please let me know if there are any performance issues. Note that modifying wmd.js only changes the implementation of Markdown in the preview. There's still no way we can control the implementation on the server. In particular, trying to escape all special Markdown characters that appear between dollar signs is a recipe for disaster because it will make the preview look right, but the actual output will still be wrong. Perhaps we could try to use javascript to escape special characters between dollar signs in the input field when somebody hits "Preview Math" or something. I'll give it some thought. 41. 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.

42.

Okay, I've replaced the default wmd.js by a custom version (see http://meta.stackexchange.com/questions/2712/a-crufty-way-to-modify-wmd) if you're really curious about the details.

Please report any problems here, either with performance (as a result of loading wmd.js twice, which shouldn't really make much of a difference), or with the preview. Remember that I don't actually have control over the server side implementation of Markdown, only the javascript version used for the preview, so a "bug" means a situation where the preview doesn't match the actual result, not a situation where we'd like Markdown to behave differently. In other words, even though it would be nice if "$f'_n=g_{n-1}$" worked properly, it should still display as "$f'_n=g_{n-1}$" in the preview, because that's how the server side version of Markdown is going to render it. The goal is to get an accurate preview of what the server will do.

43.

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:

44.

There's a method for ensuring that the mathematics always comes out correctly. You can turn off the Markdown processing on a paragraph by enclosing it in p tags. Unfortunately, as the HTML sanitiser in SE is so strict and Markdown only allows block-level tags on their own, this can only be done on a per-paragraph basis. Ideally, one would be able to write

Let's consider <div style="display: inline">$x_1 + x_2$</div>


and know that everything would work just fine. Instead, one has to type

<p>
Let's consider $x_1 + x_2$
</p>


and suffer the fact that all other Markdown syntax is turned off in that block. I guess it'd be useful to be able to turn markdown syntax off inside, say, a span element.

PS If you like this, I just posted an "answer" over at meta.SO requesting finer control: http://meta.stackoverflow.com/questions/1777/what-html-tags-are-allowed-on-stack-overflow-server-fault-and-super-user/29901#29901.

45.
+1 for Andrew's bug report about the behavior of **

I get this now nearly all the time, including in posts themselves.

Help! (or should this be filed on Meta.SE?)
46.

@Ilya: I suspect this is something to do with Anton's modified Weapons of Math Destruction so I wouldn't file over on meta.SE just yet.

47.

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.

48.
I'll see if I can do this tomorrow.
49.

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.