# Mathjax 2.4 beta

We have deployed the latest Mathjax 2.4 beta on Math.SE. As with any beta release please post an answer to this question if you find any issues. We will be monitoring this thread closely along with the authors of Mathjax to ensure this release goes smoothly.

This release includes a number of new features and increased stability. For a list of resolved issues included in this release please check here.

• $\textsf{AWESOME! } (\texttt{Yes, quite awesome})$ – Asaf Karagila May 12 '14 at 20:45
• "#794 fix spacing for \bmod." This bug bugged me way more than it should have. – Alex Becker May 12 '14 at 21:01
• @Alex: Among the maxims on Lord Naoshige's wall there was this one: "Matters of great concern should be treated lightly." Master lttei commented, "Matters of small concern should be treated seriously." (Hagakure) – Asaf Karagila May 13 '14 at 6:23
• \textsf and \texttt aren't rendering for me. Any idea what could be going wrong? – 6005 May 13 '14 at 23:29
• It looks like the TeX-AMS_HTML-full configuration file didn't get updated to the v2.4 version on beta.mathjax.org. Not sure how that happened. We'll check into that. – Davide Cervone May 14 '14 at 0:27
• @Goos: OK, the issue has been fixed, and you should get v2.4 for everything now. Thanks for the report. – Davide Cervone May 14 '14 at 10:35
• @DavideCervone Thank you! It looks very clean. – 6005 May 14 '14 at 10:38

The limits of integration aren't being positioned correctly in \textstyle mode (the default mode for in-line equations). The upper limit overlaps with the integral sign due to being rendered directly above the lower limit, and I get the feeling that the lower limit is a bit off, too. $\int_0^t f(x)\,dx$

$$\textstyle\int_0^0$$

Checked in Firefox 32.0a1 on OS X 10.9.2 and Safari 6.0.5 on OS X 10.8.4. Screenshot:

• I don't have the same problem in Windows 7/Chrome. I think it would help if you posted a screen shot of the resulting render. – Daniel R May 13 '14 at 7:12
• @DanielR My bad for assuming that it was universal. Duly noted and edited. – epimorphic May 13 '14 at 7:21
• I see this bug too (Chrome on OS X). – Grigory M May 13 '14 at 8:08
• Thanks. Filed for Safari at github.com/mathjax/MathJax/issues/820 (We can't relibly test for FF 32 since it's the current nightly builds. But we'll keep an eye out.) – Peter Krautzberger May 13 '14 at 8:49
• @GrigoryM I've added Chrome 34 on OSX8 to the issue. – Peter Krautzberger May 13 '14 at 8:56
• As a stop gap, you could switch to SVG output; it does not seem to suffer from this issue. – Peter Krautzberger May 13 '14 at 9:43
• This seems to be specific to the STIX fonts. I'm checking into it. – Davide Cervone May 13 '14 at 13:22
• I found the problem, and it will be fixed in the official v2.4 release. Thanks for pointing out the issue! – Davide Cervone May 26 '14 at 20:49
• We just pushed an update of 2.4-beta that should fix the issue. Could you clear you cache and see if it's resolved for you, too? – Peter Krautzberger Jun 2 '14 at 16:24
• @PeterKrautzberger Yes, both limits now seem to be correctly positioned. Thanks for the fix! – epimorphic Jun 2 '14 at 21:06
• Thanks for confirming! – Peter Krautzberger Jun 3 '14 at 6:01

I noticed a problem with spacing in superscipts, like in $e^{x+iy}$: $i$ and $y$ overlap a bit, maybe it's a problem with the beta version?

Here is a more extended illustration (see the answer): Trigonometric identity involving sum of "Dirichlet kernel like" fractions

Here are images, for comparison:

• I don't have the same problem in Windows 7/Chrome. I think it would help if you posted a screen shot of the resulting render. – Daniel R May 13 '14 at 7:13
• I have the problem on Windows 7 and Firefox 29.0.1, but not on Windows XP with the same Firefox (but at the link I give above, the font is still very small). Same remark for the problem noticed by epimorphic. I'll send a screenshot asap. – Jean-Claude Arbaut May 13 '14 at 7:49
• I'm unable to reproduce this, see saucelabs.com/bugs/c622aac69d5843b7b8149652574a4672 Can you share a screenshot? – Peter Krautzberger May 13 '14 at 8:51
• @Jean-ClaudeArbaut thanks for the screenshot. Looks like you have the STIX fonts installed. Still not able to reproduce this, I'm afraid saucelabs.com/bugs/084b14ad2c8e4947a044cada5428ddb7 – Peter Krautzberger May 13 '14 at 12:06
• Ah, maybe it's that, I'll have a look. Thank you! – Jean-Claude Arbaut May 13 '14 at 12:11
• @PeterKrautzberger FYI, I have no problems in Internet Explorer, Firefox, Opera and Chrome. I'm running Windows 7. – Daniel R May 13 '14 at 12:40
• Thanks, Daniel. @Jean nothing wrong with the STIX fonts. We just need a way to narrow down & reproduce. – Peter Krautzberger May 13 '14 at 12:42

The zero looks a little too large

$10$

$10$

Is that new?

• Yeah, okay, it looks different from my screen. Your screenshot clearly has a slightly bigger $0$. Maybe it's just one of those natural variations between computers. Like how not all humans the same height! :-P – Asaf Karagila May 14 '14 at 16:47
• @draks... could you provide browser and OS version as well as the fonts used (mentioned at the top of MathJax menu => about)? Thanks! – Peter Krautzberger May 14 '14 at 20:15
• I see the same thing. Newest firefox with Windows 7 home edition. – N3buchadnezzar May 20 '14 at 12:09
• I don't see this on Ubuntu 13.10 running Chrome [Stable] 35.0.1916.114. Could it be ClearType on Windows? – Cole Johnson May 26 '14 at 2:05
• @PeterKrautzberger the same as N3buchadnezzar... – draks ... Jun 2 '14 at 11:41
• @N3buchadnezzar & draks could you give a specific Firefox version? Also, we just pushed an update to 2.4-beta. Could you clear your cache to see if the problem persists? – Peter Krautzberger Jun 2 '14 at 16:24

The Zoom feature is fairly useless as it includes the left hand indentation. Try it in the same question as previously mentioned in other answers. Even at the minimum zoom of 125% it is almost unreadable because of the extra wrapping required:

Actually, try it on the next answer: You'll see part of the problem is simply excessive breaks being inserted, even when there's no indentation.

I should mention the Zoom feature does look good for small samples, like on the comments and other answers to this question.

• This seems to have been fixed, except, either there does need to be some wrapping when the zoom is big enough to cause the displayed maths to venture past the RHS of the background box, and/or, the background box does need to be increased in size. – Mark Hurd May 17 '14 at 9:21
• The reason there is spacing in this zoom box is that the equation includes a tag. Tags are supposed to appear at the right margin, and to accomplish that, MathJax makes the equation "full width" with the tag at the far right, and the rest of the expression centered in the full width. (That is different from untagged expressions, which are their natural width, and the browser does the centering.) That means that the zoomed version of this has to deal with the full width expression as well. For me, the expression extends beyond the box, and your may as well at the bottom (off screen). – Davide Cervone May 19 '14 at 21:33
• I've opened an issue tracker for this. – Davide Cervone May 19 '14 at 21:34
• The excessive breaks issue seems to be a bit of a heisenbug. I don't see it when I'm editing and sometimes it goes way when just looking at an existing Q&A without refreshing. Refreshing is actually more likely to cause the problem to come back. For reference, the other questions I'm seeing it are here and here. – Mark Hurd May 23 '14 at 13:00
• We just pushed an update of 2.4-beta that should fix the issue. Could you clear your browser cache and see if it's resolved for you, too? – Peter Krautzberger Jun 2 '14 at 16:25
• @PeterKrautzberger The bounding box problem I reported in my post seems to have been fixed, although I would like the LHS indent to be reduced or ignored when zooming in. However, the excessive breaks issue is still present in the examples I've already linked to, and it still goes away at its own accord. – Mark Hurd Jun 3 '14 at 1:22
• It may be that the line break width is not being reset properly from whatever was the last expression typeset, so that could cause the erratic line breaking behavior you are seeing. I'll check into that. The indenting is due to centering, and that is not likely to change (though without the extra line breaks, it may be smaller). – Davide Cervone Jun 3 '14 at 10:31
• On the bounding box issue, some sort of minimum is needed too. Check this rather pedantic case. – Mark Hurd Jun 3 '14 at 15:13