@Anton: I tried clearing my cache, but it's still doing it in both versions of Firefox.

In the above question after adding some back-ticks the problem seems to go away on OS X chrome, but stil live on in iPad safari. Meh.

@Evan, @Anton,

For cross-site use (e.g. resources residing on latex.mathoverflow.net) Firefox requires font-files to be delivered with the HTTP header
Access-Control-Allow-Origin: *

On mathoverflow this header isn't set so the font-files aren't applied and MathJax falls back to font images.
This HTTP header is also required for cross-site font-files in IE9.

For Apache, something like the following in an appropriate .htaccess file would work:
<FilesMatch "\.(otf|eot)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>

EDIT:
Actually, I forgot that this is already in the documentation. See the Notes about Shared Installations at http://www.mathjax.org/docs/1.1/installation.html

@shogun70: We already have such an .htaccess file. See this thread.

@Scott M: (not in response to anything he's posted here recently) How much control do you have over Apache? Can you tell it to gzip MathJax as shogun70 suggests?

@shogun70: Holy moly, you're right! It looks like I screwed up the upgrade to MathJax 1.1 and called the file .htacess instead of .htaccess. It should be corrected now. Thanks for catching this!

It's comments like that which make me wish that meta.MO had a soundtrack. There ought to have been some menacing music building to a crescendo at the words "root access" (with possibly some manic laughter off-stage).

Okay, I think I added the DEFLATE filter. Could someone (@shogun70?) check that it's working?

Actually, I'm a bit confused about our .htaccess files for latex.mathoverflow.net. @Anton, the .htaccess I added a line to didn't have anything about "Access-Control-Allow-Origin", and I couldn't find any others. Where did you do this?

@Scott: Yes, the files are being gzip'ed now.

@Anton: You've found a MathJax documentation error - that location will work (is working) for .otf files (needed for Firefox) but not .eot (needed for IE9). I can't check mathoverflow.net with IE9 until tomorrow, but I assume it is rendering math with image fonts.

The mathjax1.1/fonts/HTML-CSS/TeX/otf/.htaccess file should be moved to an ancestor directory of the one it is currently in, or merged with the .htaccess file in the top directory (mathjax1.1/.htaccess).

I asked this as a separate discussion, but probably it belongs here.

The command \mathit seems to be completely ignored in LaTeX input. This yields exceptionally ugly results at times, eg, here. Why does this happen, and can it be fixed?

(\textit likewise does not work right.)

@Anton: your second snapshot is about what I see, and is horrendously ugly. I'm very surprised you don't see that. Look at the spacing between the 'f's. It's doing the thing TeX does by default, which is to typeset anything in math mode as though it were a product ("D times i times f times f"), which is not all what is intended.

I doubt it's a rendering issue, since it also shows up for me in Chromium. This is obviously and typically a conversion issue; this is what you get if you just enter italic text in math mode without protection. See also theojf's answer in the separate thread I started on this, before realising it should be here.

If you want me to report the bug, I need to know details like which version of MathJax you're using and how it's configured.

geraldedgar: I think the double dollar signs confused the parser, or maybe the subscripts. I added backquotes around the displayed math and it fixed the issue.

If it was the subscripts, that's a known issue that's been discussed on meta before. Subscripts and asterisks are both parsed as MarkDown and occasionally need to be escaped by a backslash to be used properly.

The processor gets confused on the admittedly complicated case where a \text block contains math. For example, I couldn't typeset the legitimate TeX code \Ext^1_{\text{$\mathbb F_p$-alg}}. (It is surely possible, but I think unsatisfactory, to type instead \Ext^1_{\mathbb F_p\text{-alg}}.)

When viewing an MO page, I got a pop-up telling me to go to this page: http://www.mathjax.org/help/configuration/

I assume this needs to be done server-side.

Probably MathJaX read the definition in the textarea which comes before the preview box and so the newcommand was in effect when the preview box was parsed. This relationship was, obviously, changed when you saved your answer.

I'm getting the same kind of popup voloch mentioned several weeks ago. Whenever I load a mathoverflow page, I get the following popup message:

MathJax no longer loads a default configuration file; you must specify such files explicitly. This page seems to use the older default config/MathJax.js file, and so needs to be updated. This is explained further at

http://www.mathjax.org/help/configuration

Added: Clearing my browser cache seems to fix it.

The LaTeX \begin{enumerate} command seems not to work either with or without back tics. Is there a good substitute?

Thanks, Andrew.

I used

<a href="http://en.wikipedia.org/wiki/Johnson%E2%80%93Lindenstrauss_lemma">Wikipedia</a>

in a post, but it did not render properly. I see that it also does not render here on Meta at all. Why? Survit edited it to

Wikipedia

which worked fine, but I thought ordinary HTML links worked.

Hehe, witness above my failed attempt to use a <pre> tag to prevent Markdown parsing the square brackets. Bumps indeed!

(This isn't a MathJaX isssue, by the way.)

The link (and Scott's <pre> attempt) doesn't work here because the Markdown filter here strips out HTML tags before processing. So any HTML tags get escaped. (Although this stripping is not 100% safe).

On MO, some HTML is allowed, including <a> tags (what is and isn't allowed is governed by a "whitelist" that is listed somewhere on meta.SO). When I cut and paste the code you gave into a blank "Ask a Question" then the preview converts it to a link. So either there's a difference between the preview and what is actually rendered (unlikely in so simple an example) or there's more to your example than just the link. Could you link to the actual post?

More generally, Markdown and HTML are not really meant to mix.

That is about as wrong as it can be! Markdown and HTML are meant to mix. Markdown goes out of its way to be polite to HTML: if it spots any HTML then it says, "I assume that the user knows what they are doing and will just let this go through.". The problem is that many people who've implemented their own version of Markdown have decided that the average user does not know what they are doing and so put in a pre-filter to strip out anything Bad. These pre-filters are complicated because they have to understand both HTML and Markdown. What they should have done is put in a post-filter to check that the final rendering is clean as the post-filter only has to understand HTML.

(Naturally, the nLab and the nForum get it right.)

It isn't the underscore, it's the dash. Whoever created that page on Wikipedia used an ndash to hyphenate the names. Whilst this is technically correct, it makes the link somewhat tricky to type in! You need to be able to type in unicode URLs. StackExchange's Markdown parser only allows certain things in its HTML (see my comment above about sanitising). It would seem that unicode is not allowed. So what Survit did was to replace the unicode character by its "escaped" version - that's the percent stuff.

There's ways to find these escapings, but I don't know of one off-hand. (I would have thought that Wikipedia would automatically make redirects to "sanitised" versions of pages, but I can't find one for that page itself).

Usually, Markdown's own syntax for links is better than using raw HTML, but in this case even that doesn't work. The escaping method is the only one that I can make work correctly. (On the other hand, the Markdown syntax does work correctly here: [Wikipedia](http://en.wikipedia.org/wiki/Johnson–Lindenstrauss_lemma) correctly produces Wikipedia).

I just tried on the SE2.0 system and witnessed the same behaviour, so this wouldn't be fixed by migrating!

Yes, IME, the browser (Firefox) escapes all cut-and-paste URLs automatically so that it all works out, but I suspect that some other browsers may get it wrong. As for replacing en-dashes with hyphens, this only works on Wikipedia because they have a general policy asking article authors (or renamers) to provide redirects in such cases, it is not guaranteed to work in general on other sites.

If you look at the source of your original post, it reads:

For the basic result, start with

<a href="http://en.wikipedia.org/wiki/Johnson–Lindenstrauss_lemma/">Wikipedia</a>

or Google "Johnson-Lindenstrauss Lemma".

In the URL, there is a /. Since I cut-and-pasted from that to do all my experiments, a lot of them had a trailing slash. Sometimes that doesn't matter, sometimes it does. I will freely admit that I should have spotted that and removed it before doing further analysis. Ultimately, the en-dash was the real reason why it didn't work, the trailing slash was what meant that I didn't spot that putting in an ordinary hyphen did work.