Not signed in (Sign In)

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


    Bug report:


    ah, Greg's trick fixes this.


    I don't like Greg's trick. It wraps the mathematics in a code block when it isn't a code block and relies on the jsMath to ignore the code block. I suspect that this could look horrible in the wrong browser. Also, it's like using a screwdriver to hammer in a nail: it's not the proper use of this syntax so this won't be taken into account if there's a proposal to change the behaviour.

    Wrapping the mathematics in p-tags is cleaner because it turns Markdown off inside the block and this is the intended behaviour of putting a block in a p-tag. Admittedly, it means that you can't use Markdown syntax elsewhere in that paragraph, but that's no great hardship.

    That particular entry still wasn't displaying correctly so I put in p-tags to fix it and it now looks right to me.


    Regarding the double-star in the preview, I get the problem even when it's in the middle of a line. That is, saying writing "So by **Banach-Steinhaus** we get ..." then the preview shows "So by *Banach-Steinhaus* we get ..." (actually, I'm not sure if the stars are within the italic or outside).


    Not so much a bug with jsMath, just one to add to that "jsMath Ain't LaTeX" list: \cdots doesn't work. It appears to produce a list of less-than-or-equal-to signs. I've seen this a couple of times (most recently by David Speyer, no less) so figure it ought to be noted somewhere.


    Regarding \cdots, I can't reproduce the error. It works as expected.

    On the one hand, I agree that Greg's trick is crufty, but it's actually a really nice way to tell Markdown to leave the underscores alone, and if you're using an old browser (or browsing with javascript disabled), I don't feel like the <code> tags are disturbing.


    I've implemented danlec's live preview, which should be awesome ... no more "Preview Math" button necessary. I think this makes it all the more desirable to make the preview match the final post as closely as possible. I'll try to work on it later this week. If anybody is interested in helping debug/code (Ilya?), let me know if you do anything so that we don't cover the same ground twice.


    Apparently, the live preview doesn't work properly on IE7. Does anybody know why this happens and how to fix it?


    Maybe the cdots is a font issue. I'll see if I can experiment a bit. I thought I'd seen it at work (where I have the STIX fonts installed) but maybe it was just at home (where I do seem to have a few missing symbols). Next time I see it, I'll take a screenshot.


    Is there an equivalent of \operatorname in jsMath? I am guessing the answer is “no” or “not in an obvious way”, since Andrew didn't get his supp right, and knowing him, I think he would if he could.


    *looks at floor in shame*

    I suspect that that was a hangover from using itex over at the n-lab. If something isn't an operator, just putting 'hello' defaults to an operator (which is why it's terribly important there to write 'f g' and not 'fg'). I'm used to these web LaTeX clones being a subset of LaTeX so I try to tread carefully and not assume that commands work, especially if they're not "mainstream" ones. It would be useful to have a quick summary of the differences and what does work easily findable.


    @hanche: \operatorname seems to work just fine for me.

    • CommentAuthorKevin Lin
    • CommentTimeNov 19th 2009 edited
    I also don't like Greg's trick, though that's what I've been using. Why don't you just scrap the _'s and *'s and **'s and allow HTML tags for italics/bold/underline instead? Similarly, why not allow HTML links rather than links [like this][1]?

    [1]: http://blah

    If anybody is interested in helping debug/code (Ilya?)

    The regexps in wmd.js scare me! If nobody volunteers to fight them, I'll eventually get to that, but it may not be exactly soon.



    HTML tags are allowed in the Markdown.


    @Kevin and Ilya, yes but only a very limited list and then you have to get the attributes exactly right. There's a question on meta.S[OE] about this somewhere.


    Only a limited set of html tags are allowed to prevent cross-site scripting and other exploits. Here's a list of all allowed html tags.


    Note also Anton's comment on that list; this issue surprised me.


    jsMath appears not to have the $\mod$ command.

    I'm not sure if I was doing something wrong, but the live preview did not display the math symbols when I asked this question
    (I was using IE 7.)

    (I've fixed the link in response to David Speyer's post below.)

    The link in amatthew's post is broken. The correct link does not have a period at the end.


    Regarding mathfrak, Anton, can you try adding the following?

    jsMath.Macro('mathfrak','\\eufm #1 ',1);

    @Scott: I did this, which seems to work (some of the details of why things have to be in this order are still a mystery to me

    jsMath.Parser = {prototype: {macros: { mathfrak: ['Macro','{\\eufm #1}',1], operatorname: ['Macro','\\mathop{\\rm #1}',1], implies: ['Macro','\\Rightarrow'], Diamond: ['Macro','\\diamondsuit'], mod: ['Macro', '\\mathop{\\rm mod}'] }}}; ...various other jsMath stuff... jsMath.Font.Load("eufm10");

    upshot: \mathfrak, \operatorname, \implies, \Diamond, and \mod should now work as expected.


    Regarding regexps in the modified wmd.js:

    I don't have any experience of the peculiarities of javascripts interpretation of regexps, but I have messed around with them in perl and php. I've tried a few things on the test site, and played with a javascript regexp tester.

    First, some general advice:

    1. The classes for before and afters are best defined by exclusion rather than inclusion.

    2. I think that trying to do both stars and underscores in the same regexp is doomed. The problem is that _**a** produces _**a** but ***a** produces *a. So trying a simple exclusion match is problematic.

    3. It seems that the don't-convert-mid-word-stuff applies to the start of the markup, not the end. So Un*believable* doesn't get converted but *Un*believable does.

    4. However, the stuff afterwards does matter when it is a star or underscore. Thus *a** is not converted, but *a*_ is, whilst **a* is converted (to italics), whilst _*a* is not.

    5. Learn about the 'm' and 's' flags: one of the problems with the current regexp is that it doesn't match at starts or ends of lines. By using the 'm' and 's' flags correctly, one can overcome this without too much difficulty.

    The following worked on my test suite for double stars:


    I haven't yet figured out the single stars version (the tester seems to be going haywire).


    Is someone looking at Fedja's comments here, to try to figure out what went wrong?


    I started writing a Markdown torture test, which we can use to test proposed modifications to the way wmd.js handles italics and bold. Ideally, we should change wmd.js to produce exactly the same (crazy!) output.

    This modification of Andrew's regex works pretty well for bold: (?:^|[^A-Za-z_\\])(\*\*|__).*?(\*\*|__)($|[^A-Za-z\\]) but I can't quite get something that matches the following line properly: **internal _'s and *'s (even __'s and **s) don't** break bold (note that "**s) don't**" wasn't converted separately ...) which should produce

    internal _'s and *'s (even __'s and **s) don't break bold (note that "s) don't" wasn't converted separately ...)

    I'll see what I can do about italics later. If you're going to experiment with it, remember that wmd.js does the bold conversions first, so you should change all matching double stars/underscores to <strong> and </strong> before applying your regex.


    I've changed the italics/bold conversion function on MO and faketestsite to do the following replacements in the following order: text = text.replace(/(^|[^A-Za-z_\\])(\*\*|__)(.*?[^ \\])(\*\*|__)($|[^A-Za-z\\])/g, "$1<strong>$3</strong>$5"); text = text.replace(/(^|[^A-Za-z_\*\\])(\*|_)([^ \*_][^\*_]*?[^\*_ \\]|[^\*_ \\])(\*|_)($|[^A-Za-z\\])/g, "$1<em>$3</em>$5"); text = text.replace(/(^|[^A-Za-z_\*\\])\*\*([^ _][^&lt;]*?[^_ \\]|[^_ \\])\*\*/g, "$1<strong>$2</strong>"); text = text.replace(/(^|[^A-Za-z_\*\\])\*([^ _][^_\*&lt;]*?[^_ \\]|[^_ \\])\*/g, "$1<em>$2</em>");

    This seems to fix all bugs I've come across. I challenge somebody to find a discrepancy between the preview and the final output (having to do with italics and bold; I know there are some other issues).

    • CommentAuthorHarry Gindi
    • CommentTimeNov 29th 2009 edited
    It appears that Reid Barton's answer to my question is bugged up from jsmath, given that everything is overflowing off of the page near the bottom.
    Bug report:

    Use $*$ twice in the same paragraph. For example:

    "Vakil's condition $*$ is really powerful. I don't know what I'd do without $*$."

    The preview shows this as displaying correctly, but in fact it will not.

    To emphasize, the bug is not that *'s have to be escaped, I know that. The bug is that preview does not know they have to be escaped.
    This is a meta-comment; it'd be nice if this thread were more easily reachable, like, say, linked on the sidebar or possibly stickied at meta. As it is, if you have an annoying problem with jsmath, you have to go to the FAQ and read nearly the entire section before you find a link here, and even then it reads more like it's for bugs with the preview than for bugs with general jsMath rendering.
    Or maybe sticky this?
    I agree, this should be sticky.

    I'd rather a wiki-like page for recording hints and tips for jsMath. Even if this thread were reachable, it's hard to slurp through the whole morass looking to see if your particular issue has been dealt with already.


    I've added a link to this thread from the "How to write math" sidebars and made the discussion sticky.

    • CommentAuthorKevin Lin
    • CommentTimeDec 26th 2009 edited

    The math in my answer here keeps spilling over the right margin. Actually, I just installed the jsmath "special fonts" earlier today. I had very minimal right-margin-spillage problems prior to this; now I seem to be having many. So I guess it's probably because of the fonts. I'm using Safari 4 on a Mac, if that matters.

    • CommentAuthorrwbarton
    • CommentTimeDec 26th 2009
    @Kevin: yes, this bug (overflowing jsmath text with space on the next line in Safari and Chrome) has been mentioned on this thread previously.

    Btw, the preview/final output discrepancy bug has been completely fixed on SO. Hopefully those changes will be merged into SE soon.


    Somebody reported the following problem with jsMath to me. Browsing this question with Safari on a Macbook, instead of getting the correct output (left), he gets the output on the right:

    jsMath win jsMath fail

    I've asked him to check if he also has the same problem with MathJax's preview page.

    @Anton: Just for the record, I use Safari 4 on a MacBook Pro and I see the correct output, both that of the question and of the MathJax preview page. I did install the jsMath fonts.
    Works fine for me, Safari 4.0.3 on an iBook. Does the user have jsMath fonts installed?

    I'm pretty sure he doesn't have the fonts installed, so it's a problem with the image fonts. It must be related to the problem Andrew reported with \cdots earlier in this thread.

    He's also just confirmed that everything looks good with the MathJax preview page.


    Works fine for me, Safari 4.0.4 on an MacBook Air, no fonts installed.


    Out of curiosity, why is this no longer sticky?


    I unstickied it more or less on a whim last night. The reasoning was that it's been a long time since a bug was actually reported here rather than reported elsewhere and copied here by an old hand, and that this thread is likely not very useful to anybody who didn't read it as it was happening. But I guess that was as true (or false) three weeks ago when it was requested that this thread be sticky, so I'll re-sticky it. Sorry about the confusion.

    I messed with the jsmath controls one time too many, and now each time I open a question I get a popup saying:
    "For security reasons, framing is not allowed; click OK to remove the frames."
    and then the page proceeds to reload indefinitely, each time coming up with the popup and restarting.

    I can't access the jsmath panel in mathoverflow; I tried accessing it from other websites and changing the settings, but that didn't have any effect (I don't know what going global is supposed to do, but no luck with my problem there). I also tried to change settings through but I don't think that had any effect either.

    Is there any way I can completely reset my jsmath config? I couldn't find anything after searching.

    @Sam: Try deleting the jsMath cookie from That resets all the jsMath settings to default for me.

    That worked, thanks a lot.
    • CommentAuthoralgori
    • CommentTimeJan 13th 2010
    There is a slightly annoying problem I've encoutered: if there are more than 1 asterisk in a paragraph, everything between certain pairs of asteriscs does not show properly. Is there a way to fix that?

      CommentAuthorJon Awbrey
    • CommentTimeJan 13th 2010 edited

    Does escaping the asterisk with a slash in front work?

    • CommentAuthoralgori
    • CommentTimeJan 13th 2010
    Thanks, Jon! I'm not sure what escaping means, but this worked!