31
$\begingroup$

Today we are entering the public beta phase of MathJax v2.5. This release focused on improving rendering speed and MathML support.

The 2.5 release improves the speed of the HTML-CSS output by 30-40% (depending on content complexity, with higher gains in more complex situations) and introduces a new preview output (CommonHTML) which currently provides a rougher layout but is ~10x faster than the HTML-CSS output; in the long run, the CommomHTML output will reach the quality of the HTML-CSS and SVG outputs.

In terms of MathML support, Content MathML is now fully supported via a new extension and we have improved the experimental support for elementary math elements (with special thanks to contributions from David Carlisle). The 2.5 release also includes over 70 bug fixes to increase the quality and stability of MathJax (see here for details).

If you see any issues please report them here on meta as we are monitoring.

$\endgroup$
25
  • 2
    $\begingroup$ A minor thing: The fix for the spacing "bug" reported here appears not to have been incorporated in this release. $$\binom12+\binom12$$ According to the issue tracker something seems to have been done about it a few months ago. $\endgroup$
    – Daniel R
    Jan 6, 2015 at 17:18
  • 3
    $\begingroup$ Note: this is still a beta release, not the official 2.5 release. Also, it looks like meta.Math.SE has gone back to the official 2.4 release rather than the 2.5 version (at least that is what I'm currently getting). You can check by using the MathJax contextual menu and selecting "About MathJax". The URL used in the website is currently the regular CDN address rather than the beta address, so 2.5 isn't currently being used, here. $\endgroup$
    – Davide Cervone
    Jan 6, 2015 at 17:51
  • 1
    $\begingroup$ My mistake - 2.5 is now active again. Sorry for the confusion @DavideCervone $\endgroup$
    – Geoff Dalgas
    Jan 6, 2015 at 17:57
  • 1
    $\begingroup$ Thanks! The spacing now looks good for me in @DanielR's comment and in the linked page. $\endgroup$
    – Davide Cervone
    Jan 6, 2015 at 18:00
  • $\begingroup$ @DavideCervone It does indeed look good now! $\endgroup$
    – Daniel R
    Jan 6, 2015 at 18:19
  • 2
    $\begingroup$ @DanielR On my side it displays like this. The gap seems huge to me. $\endgroup$
    – Git Gud
    Jan 6, 2015 at 19:42
  • 1
    $\begingroup$ @GitGud That's what it looked like for me too until I refreshed the browser. Did you try shift+reload? $\endgroup$
    – Daniel R
    Jan 6, 2015 at 20:04
  • $\begingroup$ @DanielR I refreshed, it worked. Thanks! Did it happen that this was fixed right after I opened the link? I opened the link just a few minutes before I entered my comment. Edit: I just realised the time stamps on your and Cervone's comments above, so this isn't what happened. $\endgroup$
    – Git Gud
    Jan 6, 2015 at 20:18
  • $\begingroup$ @DavideCervone In this post, the construct $\overline{T}^i$ no longer renders. It seems that it worked previously. $\overline{T}_i$ still works. $\endgroup$
    – user147263
    Jan 6, 2015 at 21:41
  • $\begingroup$ OK, thanks. I'll look into it. There were changes to \overline and \underline for other reasons, and that will need to be fixed. In the meantime, you can use {\overline{T}}^2 if you want. $\endgroup$
    – Davide Cervone
    Jan 6, 2015 at 21:59
  • $\begingroup$ @GitGud, you probably had a cached version of MathJax from the last time you were on the site, and that doesn't get refreshed unless you force the refresh (or the cached version expires). The forced refresh got you the new copy. $\endgroup$
    – Davide Cervone
    Jan 6, 2015 at 22:02
  • $\begingroup$ @DavideCervone I see, thanks. $\endgroup$
    – Git Gud
    Jan 7, 2015 at 0:05
  • $\begingroup$ There appears to be display issues when viewing someone's answers on their profile page. Some titles will be broken up (sometimes in weird places) and displayed over 2 lines. $\endgroup$
    – Random Variable
    Jan 7, 2015 at 4:15
  • 2
    $\begingroup$ In Chrome 39.0.2171.95 m, I see a blue box around equations when I click on them: i.imgur.com/LUjGxyx.png $\endgroup$
    – Najib Idrissi
    Jan 7, 2015 at 8:22
  • $\begingroup$ @NajibIdrissi thanks. tracking this on github.com/mathjax/MathJax/issues/997 $\endgroup$
    – Peter Krautzberger
    Jan 7, 2015 at 11:33

12 Answers 12

Reset to default
8
$\begingroup$

This isn't necessarily a bug, but on my (very slow) computer binomial coefficients {n \choose r} ${n \choose r}$ render very weirdly at first, until you wait for the rendering to finish at which point they render correctly. At first they appear as four sets of parentheses; the first of the parentheses on the left side is large while the rest are small, and the first of the parentheses on the right side is large while the rest are small.

Here is a screenshot:

enter image description here

And a close-up (sorry for the poor quality):

enter image description here

Again, isn't really a big deal, as it fixes itself when you wait. But this behavior seems pretty unexpected.

$\endgroup$
4
  • 1
    $\begingroup$ Thanks @Goos. Tracked at github.com/mathjax/MathJax/issues/998 $\endgroup$
    – Peter Krautzberger
    Jan 7, 2015 at 11:39
  • 3
    $\begingroup$ This is due to the fact that the CommonHTML output didn't implement the underlying format that is used by \mathchoice (which is what is used to implement \binom and related constructs). What you are seeing is all four choices rather than only the one for the correct output type. That should be fixed. $\endgroup$
    – Davide Cervone
    Jan 7, 2015 at 12:50
  • 2
    $\begingroup$ We have pushed an update to the CDN, so you should not be seeing the multiple parentheses any longer. $\endgroup$
    – Davide Cervone
    Jan 7, 2015 at 17:27
  • $\begingroup$ @DavideCervone Okay, thanks!! $\endgroup$
    – Caleb Stanford
    Jan 7, 2015 at 17:27
7
$\begingroup$

The rendering of radicals seems to behave a bit erratically at times. Specifically,

  1. the tying of the root symbol to the bar over the rooted expression is not seamless,
  2. the thickness of the bar line is not consistent and seems to depend on the expression, but the dependence is not entirely clear, and
  3. the extension of the the bar line past the rooted expression appear not to be consistent.

Screen shot examples of the above (generated by $$\sqrt{7}\qquad\sqrt{77}$$ and a zooming in a lot in the browser):

Screen shot

I haven't been able to find a consistent behavior, but it appears to have something to do with the zoom settings in the browser and/or the use of \large or similar size-setting commands. A not very educated guess is that it's the conversion from vectorized graphics to bitmapped images of the bar line that borks.

The post that made me report this was this one, where the $\sqrt3$'s look less than perfect on my computer. Screen shot:

enter image description here

(Interestingly, the last $\sqrt3$ is rendered slightly differently compared to the first two.)

This might not be related to changes in this particular beta release; I have a vague recollection that I have seen it before. Nevertheless, I thought I'd go ahead and post it here anyway, since you might be more active with bug fixing at this stage of the development.

Setup: Win 8.1, Chrome Version 39.0.2171.95 m

$\endgroup$
5
  • 2
    $\begingroup$ The situation is complicated, so it may take several comments (sorry). Getting the line and the surd to match up is delicate, and I have not been successful on getting something that works perfectly in all browsers. MathJax has only a rough idea of the pixel-to-em ratio that is needed to do the positioning of characters, and the quality of that ratio depends on the browser, the OS, the zoom level, the font size, and a number of other factors. Chrome is particularly finicky about its positioning, and you can see that the line is too low in your screen shot... $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 17:38
  • 2
    $\begingroup$ ... The positioning actually depends on the zoom level, so zooming MathJax output after it is created can produce different results from zooming and then reloading the page (so MathJax renders at the zoomed size). This is apparent in the thickness of the line over the 7 in your first example above, for instance. MathJax tries to use characters (repeated minus signs) to form the horizontal line. This is because the browser will antialias the character so the weight fits the rest of the equation better, and also because the browser won't drop the character at small sizes as it does lines... $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 17:43
  • 2
    $\begingroup$ ...such as border lines. But if the required line is shorter than the character used, MathJax will use a horizontal line (a CSS border line) to make square root. This is what is happening in your first example. Because the browser will drop such lines at small magnifications, MathJax makes it a bit thicker in order to try to avoid that, which you can see in your zoomed example. You can see there is no anti-aliasing, and so it doesn't match the other characters' weight as well... $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 17:48
  • 2
    $\begingroup$ ... As for the extra space on the right, I'll have to check into that. It may be due to the lack of precision in positioning and knowledge of the pixel-size. But it could also be an error in the code, so I'll check into it. $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 17:49
  • 3
    $\begingroup$ Many thanks @Davide for your very detailed response. It seems you have thrown the kitchen sink on the, admittedly not very big, problem multiple times, and it does seem a bit frustrating to ensure compatibility among browsers, operating systems etc etc. Luckily, the work also seems very interesting, and I learned a lot just from reading your comments, so I thank you for that! $\endgroup$
    – Daniel R
    Jan 9, 2015 at 20:18
6
$\begingroup$

I have originally posted this as a separate question (10k+ link), but Daniel Fischer then pointed out that this was already mentioned here in comments. Since I already had screenshots ready, I though that the best thing is to move my post here as an answer. (So that it is a bit more visible than just in comments.)

I have noticed that in list of answers (in users' profiles) sometimes the title is divided in two lines in a way which seems strange to me. It looks as if the title was divided into two lines, but part from the middle of the title is put on the new line.

For example this question $A \oplus B = A \oplus C$ imply $B = C$? (in case the title will be edit, it is "$A \oplus B = A \oplus C$ imply $B = C$?" at the moment) is shown as follows:

screenshot 1

screenshot 2

Another example is this question $(A\cap B)\cup C = A \cap (B\cup C)$ if and only if $C \subset A$ (The title is "$(A\cap B)\cup C = A \cap (B\cup C)$ if and only if $C \subset A$" at the moment.)

screenshot 3

screenshot 4

You can see the questions here on page 7 and page 8. (Of course, when that user posts some new answers, these particular answers will move to other pages.)

I certainly agree that even though this might probably be a bug, it is not much of an issue. (It does not cause any big problems.)

$\endgroup$
3
  • $\begingroup$ As you point out, this is discussed above (in this comment in particular). Because MathJax is getting the wrong line-breaking size, it feels like it has to break things that it shouldn't, an in particular, it is breaking in-line equations, and that doesn't produce very good results (the inline expression is treated as a block, rather than two blocks, so that is why parts of your expressions appear below). $\endgroup$
    – Davide Cervone
    Jan 19, 2015 at 0:04
  • $\begingroup$ It would be best if the configuration for MathJax on the profile pages would turn off line breaking. But I am thinking about what MathJax might do to get the correct line breaking width, or perhaps limiting the line breaking for inline equations. $\endgroup$
    – Davide Cervone
    Jan 19, 2015 at 0:06
  • $\begingroup$ Another post about the same issue: meta.math.stackexchange.com/questions/19492/… $\endgroup$
    – Martin Sleziak
    Feb 2, 2015 at 17:26
3
$\begingroup$

There is another issue: mathjax stops when I'm editing my question. See this meta-thread

$\endgroup$
7
  • $\begingroup$ I will look into it. It appears to be related to the presence of the image, but I don't know why that would matter. But if I remove it, MathJax seems to run again. I will need to do more experimenting to see what I can find out. $\endgroup$
    – Davide Cervone
    Jan 8, 2015 at 22:57
  • $\begingroup$ @Davide, Hmm, I was already testing to remove some parts of the text until mathjax behaves proper again; indeed after removal of a certain amount of the trailing text the behave seemed to become stable, but I couldn't take time to find a decisive position. I think it also happened, before I included the picture (should be reproducable by looking at the edit-history) $\endgroup$
    – Gottfried Helms
    Jan 8, 2015 at 23:09
  • $\begingroup$ Here is what I see so far: When I open the edit page, the math is not displayed, but if I perform any editing, then MathJax runs and the math is displayed. (My removal of the image was such an edit, so it has nothing to do with the image, just any edit.) This seems to be the case for any question, not just yours (if I open any other question on MSE, I get the same behavior). I see this in both Safari and Firefox (haven't tested anything else). I did see the behavior you are reporting (of not working even during edits) only once, but haven't been able to repeat it. $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 17:31
  • $\begingroup$ I will keep looking into it, but haven't been able to identify anything yet. $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 17:31
  • $\begingroup$ @Davide : hmm, I just tried again, but the hoped resurrection (when I start some more editing after the opening of the box) does not happen. I have to 1) save, 2) refresh-the-page: then I see the rendering and I need both steps when I re-edit anything. (current Firefox, Win7) $\endgroup$
    – Gottfried Helms
    Jan 9, 2015 at 18:21
  • $\begingroup$ I'll keep checking. I will try it in Windows 7 and see if that makes a difference. $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 22:08
  • $\begingroup$ I've tried Windows7 with Firefox 34.0.5, and it works as described above for me (fails initial display, but edits cause math to render). Are you using any plugins or user scripts that might affect it? Are you getting any error messages in the console log? $\endgroup$
    – Davide Cervone
    Jan 13, 2015 at 11:54
3
$\begingroup$

$\verb*\displaystyle\Huge{a \choose b}*\quad\mbox{yields}\quad$ $\displaystyle\Huge{a \choose b}$

$\endgroup$
5
  • 2
    $\begingroup$ Another option to include code would be with back-ticks: \displaystyle\Huge{a \choose b} $\endgroup$
    – quid Mod
    Jan 16, 2015 at 22:40
  • $\begingroup$ @FelixMarin, thanks for the report. It looks like the scaling of the delimiters aren't taking the current math size into account. I'll look into it. $\endgroup$
    – Davide Cervone
    Jan 16, 2015 at 22:42
  • $\begingroup$ @DavideCervone FYI, it seems that the size of the parentheses is also not depending on the enclosed expression. E.g. $$\frac12 \choose \frac34$$ $\endgroup$
    – Daniel R
    Jan 19, 2015 at 13:16
  • 3
    $\begingroup$ @DanielR, this is actually the correct behavior (i.e., that is what TeX and LaTeX does). In TeX, \choose uses \bigg delimiters when in displaystyle and \big in all other styles, regardless of the contents. MathJax got this wrong in the past, but it has been corrected in v2.5. So the example in your comment is consistent with TeX. If you want stretchy delimiters, use \left(\frac{1}{2}\atop\frac{3}{4}\right): $$\left(\frac{1}{2}\atop\frac{3}{4}\right)$$ $\endgroup$
    – Davide Cervone
    Jan 19, 2015 at 14:07
  • 1
    $\begingroup$ @DanielR, PS, this is listed in this issue in the MathJax issue tracker. $\endgroup$
    – Davide Cervone
    Jan 19, 2015 at 14:29
2
$\begingroup$

The \small -directive doesn't extend over the \tag{} - expression. For example

\small \sum_{k=1}^\infty x^k \tag{1.2} gives

$$\small \sum_{k=1}^\infty x^k \tag{1.2}$$

$\endgroup$
1
  • 1
    $\begingroup$ This is not an issue with v2.5, as it is present in the past versions of MathJax as well. I'll have to look into how hard it would be to fix this. I'm actually surprised that it does affect the tag in LaTeX, since something like \bf E=mx^2\tag{1.2} doesn't make the tag bold. I learn something new every day! $\endgroup$
    – Davide Cervone
    Jan 8, 2015 at 23:04
2
$\begingroup$

$\overline{z}^n$ fails to render (as in this answer, which I "fixed" by writing $\overline{z}\,\!^n$)

$\endgroup$
3
  • 6
    $\begingroup$ Renders for me, at least here. $\endgroup$
    – user147263
    Jan 13, 2015 at 6:18
  • $\begingroup$ No problem here either. $\endgroup$
    – mrf
    Jan 13, 2015 at 8:01
  • 4
    $\begingroup$ That sounds like the \overline problem reported by @Fundamental in the comments to the original post. It has been corrected, but you might still be using a cached copy of the earlier version of v2.5-beta. Try clearing your browser's cache and restarting the browser. PS, a better rewrite would be {\overline{z}}^n as this gets the semantics correct. $\endgroup$
    – Davide Cervone
    Jan 13, 2015 at 11:32
2
$\begingroup$

The rightmost part of integral signs seems to get cut off for me:

enter image description here

Original question: Proving that a function is Hölder-continuous

This is with Firefox 35.0 on Linux. It's MathJax 2.5.0 beta, HTML-CSS renderer, "using local STIX fonts". I'm not sure whether this issue coincided exactly with the adoption of MathJax 2.5, but I'm pretty sure it started in the last few weeks. The other renderers don't show this problem but in general are less satisfactory.

It looks kind of similar to this much older issue: Integral signs not being rendered correctly

$\endgroup$
14
  • $\begingroup$ This is indeed the older issue that you mention, and probably not related to v2.5 (though it is possible that something there makes it occur more often). The problem is that some glyphs extend beyond their bounding boxes, and the integral sign is one of those. (The reason is so that the integrand will not be so far away from the integral sign if they follow one another directly.) But some browsers clip their screen refreshes to the bounding box, and so part of the character can be lost. That is what is happening here. I don't know of a way around that. $\endgroup$
    – Davide Cervone
    Jan 16, 2015 at 13:42
  • $\begingroup$ @Davide: I recall having that issue on MathOverflow. It was fixed (locally) through the horrible hack of scaling the font to 99%. $\endgroup$
    – Asaf Karagila Mod
    Jan 16, 2015 at 23:46
  • $\begingroup$ This is being tracked in this MathJax Issue. $\endgroup$
    – Davide Cervone
    Jan 19, 2015 at 14:33
  • $\begingroup$ @AsafKaragila, the 99% scale is not a reliable fix, in general. $\endgroup$
    – Davide Cervone
    Jan 19, 2015 at 14:36
  • $\begingroup$ @Davide: I'm aware of that; although so far it works out just fine on MathOverflow. $\endgroup$
    – Asaf Karagila Mod
    Jan 19, 2015 at 15:02
  • $\begingroup$ @AsafKaragila, OK, I'm glad it works for you on MathOverflow. I tried setting scale to 99% here and it didn't help. It may be browser or OS dependent. I have seen more issues in Linux than Mac OS X, for example. $\endgroup$
    – Davide Cervone
    Jan 19, 2015 at 18:42
  • $\begingroup$ @Davide: Does 101% fix the issue? To be fair, I had a different issue with clipping, not the one with $$\int$$, but it was a clipping issue nonetheless. $\endgroup$
    – Asaf Karagila Mod
    Jan 19, 2015 at 18:48
  • $\begingroup$ @AsafKaragila, nope, still there. I'm still investigating the issue. $\endgroup$
    – Davide Cervone
    Jan 20, 2015 at 0:11
  • $\begingroup$ For me, it seems to only occur with locally installed fonts, not the web fonts. @NateEldredge, Do you have STIX or MathJax fonts installed locally? $\endgroup$
    – Davide Cervone
    Jan 20, 2015 at 0:11
  • $\begingroup$ @DavideCervone: The "About MathJax" box says "Using local STIX fonts", does that mean yes? Otherwise, how do I find out? $\endgroup$
    – Nate Eldredge
    Jan 20, 2015 at 1:23
  • $\begingroup$ Yes, that is what I mean. Can you try disabling the STIX fonts (temporarily) on your computer and see if that helps? I've only been able to reproduce the problem when local fonts are used. $\endgroup$
    – Davide Cervone
    Jan 20, 2015 at 10:44
  • 1
    $\begingroup$ For those experiencing this problem, it appears to affect only locally installed fonts, so if you force MathJax to use web-based fonts, that should work around the problem for now. I have put instructions for how to do that in the issue tracker for this bug. $\endgroup$
    – Davide Cervone
    Jan 20, 2015 at 19:58
  • $\begingroup$ @DavideCervone: Yes, that did fix it. Switching to local TeX fonts also fixed it. Thank you! $\endgroup$
    – Nate Eldredge
    Jan 21, 2015 at 3:31
  • $\begingroup$ Local TeX fonts actually refer to a local copy of the MathJax TeX fonts, so unless you have the MathJax fonts installed, selecting that will end up getting the web-based MathJax TeX fonts anyway, not fonts from your local TeX installation. Just FYI. $\endgroup$
    – Davide Cervone
    Jan 21, 2015 at 14:32
2
$\begingroup$

Note that $\uparrow x$ and $\downarrow x$ creates huge spaces between the arrows and $x$. I don't think this is intentional.

This is how it shows on my screen: enter image description here This is how I assumed it was supposed to look:

enter image description here

I'm using Google Chrome Version 39.0.2171.99m and Windows 8.1 Pro 64x.

$\endgroup$
5
  • $\begingroup$ Can you provide a screen shot of what you are seeing? The examples in your post render as expected for me. I would post a screen shot, but I don't think you can in a comment. Also, what browser and OS (and their versions) are you using? $\endgroup$
    – Davide Cervone
    Jan 22, 2015 at 14:28
  • $\begingroup$ @DavideCervone Did so. Is it working for me as it is supposed to? It looks the same also on my I.E. 11. $\endgroup$
    – Git Gud
    Jan 22, 2015 at 15:31
  • 1
    $\begingroup$ Yes, that is what it is supposed to look like. If you want tighter spacing, try \mathord{\uparrow}x. Arrows have class REL (relation) by default in TeX, and so the spacing is that for a relation. If you want to make that be different, you need to specify the class whose spacing you want. $\endgroup$
    – Davide Cervone
    Jan 22, 2015 at 19:04
  • $\begingroup$ @DavideCervone Thanks. Should I delete this answer? $\endgroup$
    – Git Gud
    Jan 22, 2015 at 19:11
  • $\begingroup$ Up to you, but since the comments include how to get the smaller spacing, it might be helpful for someone in the future. $\endgroup$
    – Davide Cervone
    Jan 23, 2015 at 17:51
1
$\begingroup$

Another small issue.

The construct

\lim_{n \to \infty}_{n \ge k}

Used to render as two subscripts on top of each other, which was convenient. Now it does not render: $$ \lim_{n \to \infty}_{n \ge k} $$ This has broken at least one post, example here.

Similar construct: $\sum_{i + j = n}_{i \ge j}$

Desired output: $$ \lim_{\substack{n \to \infty \\ n \ge k}} \quad \sum_{\substack{i + j = n \\ i \ge j}} $$

$\endgroup$
5
  • 4
    $\begingroup$ Your $\rm\TeX$ is invalid, as it is an ambiguous subscript. $\rm\TeX$ disallows it and that was supposed to be disallowed in MathJax as well, but the test wasn't being performed properly. That has been fixed in v2.5, so you need to use braces to distinguish which order the subscripts belong in. One option is \mathop{\lim_{n \to \infty}}_{n \ge k}. Another is \lim_{\textstyle{n \to \infty \atop n \ge k}}. $\endgroup$
    – Davide Cervone
    Jan 9, 2015 at 22:12
  • $\begingroup$ Note that the \textstyle in the second example in my previous comment is required in order to get the size of the limits correct. They should be script size, but since \atop produces a generalized fraction, it's top and bottom would be in script-script size. So \textstyle makes them be in script size instead, which is what you want. $\endgroup$
    – Davide Cervone
    Jan 14, 2015 at 15:08
  • $\begingroup$ @DavideCervone Okay, thanks. (I am of course aware that the construct is invalid TeX, but it had previously been valid MathJax, and philosophically speaking I don't see why it is anything other than a pain to disallow it. I always thought MathJax was more about convenience than about enforcing arbitrary syntax rules on the user.) $\endgroup$
    – Caleb Stanford
    Jan 14, 2015 at 17:31
  • $\begingroup$ As MathJax gets used in more places, it has become clear that keeping it as close to TeX as possible is a good idea. People are copying and pasting the MathJax code into other systems that use LaTeX, and when the syntax varies, that makes it harder to do so. Also, for this particular issue, it really is ambiguous what you mean. What you were getting in v2.4 is actually the first option above (nested operators with two different limits), which does not have the semantics of what you probably meant, which is a single operator with a compound limit. TeX makes you specify this for a reason. $\endgroup$
    – Davide Cervone
    Jan 14, 2015 at 21:30
  • $\begingroup$ @DavideCervone That makes a lot of sense. Thanks for the explanation. $\endgroup$
    – Caleb Stanford
    Jan 14, 2015 at 22:29
1
$\begingroup$

I don't know if it's really a bug, or if it's a bunch of other things. I can't even quantify this.

But ever since we switched to 2.5 beta, I feel that on my cellphone the MathJax rendering drains a whole lot more battery.

Browsing the site in Firefox (in full-site mode, I hate the mobile interface) drains about 1% per minute of my Nexus 4.

I don't have exact records, but I think this is three-five times more than it was a couple weeks ago. This is especially apparent on Jax heavy pages; and other sites which have much less MathJax (or other resource hungry scripts) in them.

Am I imagining things?

$\endgroup$
0
$\begingroup$

No idea if this is a 2.5 issue or not, but "\mod" gets huge spaces around it: $$x= 1 \ln 2 \sin 3 \mod 4$$ looks like

enter image description here

$\endgroup$
2
  • 2
    $\begingroup$ This is the expected behavior, compare $a \equiv b \mod n$ and $a \equiv b \operatorname{mod} n$. The first one looks better. (And that's how it works in LaTeX anyway) $\endgroup$
    – Najib Idrissi
    Jan 21, 2015 at 13:40
  • 1
    $\begingroup$ "looks better" is a different matter, but compatibility with LaTeX I can understand, and investigating that means that I know now about the "\bmod" alternative, so thanks. $\endgroup$
    – Joffan
    Jan 21, 2015 at 13:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .