51
$\begingroup$

Today we are entering the public beta phase of MathJax v2.6 beta. We are asking you to try out the new output. Be aware, this one will offer a new set of fonts. I will allow Peter Krautzberger to explain the differences in an answer to this post.

As always, we will be monitoring this post for any bug reports or missing features.

$\endgroup$
  • 9
    $\begingroup$ This new beta supports pre-generating the HTML on the server, is that something SE is considering? As far as I understand it this could provide a large reduction in rendering time, at the cost of additional complexity on the server. $\endgroup$ – Mad Scientist Sep 24 '15 at 17:02
  • 2
    $\begingroup$ When I click on a formula (in Chrome, with the new renderer), a blue box appears around it. This happened the last time too (and had been fixed). I guess the old fix could be reapplied...? $\endgroup$ – Najib Idrissi Sep 25 '15 at 14:22
  • 7
    $\begingroup$ I'm seeing a lot of problems on browsers when editing- the display no longer updates. It might just be way slower (I tend to write long answers.) $\endgroup$ – Thomas Andrews Sep 25 '15 at 22:52
  • 1
    $\begingroup$ @NajibIdrissi, this version of MathJax introduces a number of enhancements to help those using assistive technology. Among them are the ability to use the MathJax menu via keyboard, and the including of hidden MathML output that can be read by screen readers. To make the former happen, the math elements must be focusable (so that tabbing will select them). The blue box you see is the focus highlight outline, and is now the expected behavior, since clicking on a focusable item should focus it. $\endgroup$ – Davide Cervone Sep 26 '15 at 19:24
  • $\begingroup$ FYI v2.6.0-beta.1 is out with additional fixes. See my updated answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 8:54
  • $\begingroup$ Haven't been on the site in a month or more, and today I am typing and the MathJax is coming out unrendered and I am not seeing the results of typing answers at all. Could be my system, I guess, but I would be suspicious if this is a new and major change. $\endgroup$ – Mark Fischler Oct 27 '15 at 22:01
  • $\begingroup$ FYI v2.6.0-beta.2 is out with more fixes. See also my updated answer. $\endgroup$ – Peter Krautzberger Dec 15 '15 at 11:48
  • $\begingroup$ FYI, v2.6.0 has been finalized. We updated beta.mathjax.org to v2.6.0 as well so you'll be seeing the final version here now. We hope we fixed all remaining issues (well, fingers crossed ;-) ). Thank you all very much for your help and support during the public beta! $\endgroup$ – Peter Krautzberger Dec 30 '15 at 21:46
  • $\begingroup$ FYI, v2.6.1 has been finalized. We updated beta.mathjax.org to v2.6.1 as well so you'll be seeing the final version here now. $\endgroup$ – Peter Krautzberger Feb 9 '16 at 9:36

17 Answers 17

30
$\begingroup$

Thanks, Geoff! And thanks to the community for any and all feedback on the beta -- we really appreciate your comments!

Local fonts and the Common HTML output

In v2.6 we improved the so-called CommonHTML output to the quality of our HTML-CSS and SVG outputs (it's faster though).

Since this is a completely new output, we would love to get lots of feedback on it to catch any issues before the release.

Since we didn't want to force this on every user at math.SE, we're hoping that people will try it out "manually" by switching MathJax output themselves (see below for how to do that).

There's a small catch: the CommonHTML output currently only works with an updated version of our default MathJax "TeX" fonts. That's usually not a problem as most users get the fonts as webfonts.

But if you have locally installed copies of the MathJax "TeX" fonts and want to test the CommonHTML output, then we strongly suggest you update those fonts for best layout quality. Of course, the changes to the fonts are backward compatible so they work with all versions of MathJax.

Note also that OSX comes with STIX fonts installed which MathJax would use with the HTML-CSS output by default. So using the CommonHTML output means you'll be seeing a different font.

Test page

We set up this page which will do a small test to check if

a) you have MathJax TeX fonts installed (another application may have installed them for you!) b) if you need to update an installed copy.

It also includes this link to a copy of the updated fonts.

For more background, see also our release announcement on mathjax.org.

Switching to the CommonHTML output

For those users unfamiliar with the MathJax menu, you can right-click (cmd-click on OSX, double-tap+hold on mobile) an equation to open the MathJax menu. Among other features, the menu allows you to switch the output engine under

Math Settings -> Math Renderer

You can now also reach that menu via keyboard tabs and open it with space or menu keys (and navigate the menu by keyboard).

Finally, if you are using a MathML-enable screenreader, you should now be able to get it to read out expressions; for more information on the expected results see our docs.


As usual, we'll be around so please let us know if you encounter any issues.

Thanks again for all your help and support in making MathJax better!


Update to 2.6.0-beta.1

Thank you for all your feedback and bug hunting!

We've just pushed out the second beta which should fix most of the bugs mentioned on this thread (and more). See also the release milestone for recently closed issues.

Please clear your browser cache (some browsers need a restart to really clear them) to ensure you get the new update. You can check the MathJax Menu's about page for 2.6.0-beta.1.


Update to 2.6.0-beta.2

Thank you once again for all your feedback and bug hunting!

We've just pushed out the third (and final) beta which should fix the remaining the bugs mentioned on this thread (and more). See also the release milestone for recently closed issues.

Please clear your browser cache (some browsers need a restart to really clear them) to ensure you get the new update. You can check the MathJax Menu's about page for 2.6.0-beta.2.

$\endgroup$
  • 10
    $\begingroup$ For those who need an equation to click on (like me): $$A = \pi r^2$$ $\endgroup$ – pjs36 Sep 24 '15 at 16:48
  • 4
    $\begingroup$ @pjs36 The setting is per-site (cookie-based), so to change rendering on main site, you need to click an equation there. $\endgroup$ – user147263 Sep 24 '15 at 17:03
  • $\begingroup$ Foiled again, thank you for the info, @NormalHuman. $\endgroup$ – pjs36 Sep 24 '15 at 17:07
  • 2
    $\begingroup$ And if you changed the render settings on meta, and you want to take it for a test drive. This is the place to begin with!. $\endgroup$ – Asaf Karagila Sep 24 '15 at 17:11
  • $\begingroup$ Any Google Chrome extensions coming for this feature? $\endgroup$ – Léo Léopold Hertz 준영 Oct 13 '15 at 18:59
  • $\begingroup$ Hi Peter K. Please see my answer for an issue I found in the new 2.6.0-beta.2. Regards. $\endgroup$ – Mick A Dec 17 '15 at 10:09
16
$\begingroup$

Whenever I reach a question through a link to one of its answers, MathJax doesn't seem to render anything on that page after its initial run. In particular, math content in post previews (for drafts of both new answers and inline edits) and new comments are never rendered.

Compare the behavior at

Laplace transform of $t^2e^{at}$?? (question link)

with

Laplace transform of $t^2e^{at}$?? (answer link).

$\endgroup$
  • $\begingroup$ I've tried on Firefox 42 and 44 and Safari 8 on OSX 10.10, and both when logged in and when anonymous. $\endgroup$ – epimorphic Sep 25 '15 at 14:00
  • $\begingroup$ There was a mathjax error in the question causing a line to not render. Does the problem persist now that it's been corrected? $\endgroup$ – Antonio Vargas Sep 25 '15 at 15:32
  • 1
    $\begingroup$ @AntonioVargas It still persists. The links were meant to be just one example of a universal behavior (as far as I can tell). $\endgroup$ – epimorphic Sep 25 '15 at 16:25
  • 1
    $\begingroup$ @AntonioVargas: Reproduce on Firefox 41. FWIW, I'm seeing TypeError: this.isMathJaxNode is not a function in the JS console when this happens. $\endgroup$ – Ilmari Karonen Sep 25 '15 at 21:22
  • 3
    $\begingroup$ @AntonioVargas: Debugging a bit more, looks like the error happens during MathJax startup, in MathJax.Hub.Startup.HashCheck, which is called from MathJax.Hub.Startup.Hash, which is called from CALLBACK.prototype.execute. Make of that what you will. In fact, it seems that the same error appears any time the page URL includes a fragment identifier corresponding to an actual DOM node on the page, e.g. like this. Oh, and it happens with any math renderer. $\endgroup$ – Ilmari Karonen Sep 25 '15 at 21:39
  • $\begingroup$ @epimorphic, thanks, I'll check into the issue. I suspect I know what it is and it should be easy to fix. Thanks for the but report. $\endgroup$ – Davide Cervone Sep 26 '15 at 19:29
  • 7
    $\begingroup$ I started an issue tracker for this. It turns out this is due to MathJax.Hub.Startup.HashCheck() calling MathJax.Hub.Startup.isMathJaxNode() when it should have called MathJax.Hub.isMathJaxNode(). $\endgroup$ – Davide Cervone Sep 28 '15 at 23:49
  • $\begingroup$ v2.6.0-beta.1 is out which should fix this. See my updated answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 8:48
13
$\begingroup$

If a post (question or answer) has more than $5$ comments and the link "show $n$ more comments" must be clicked to see them all, when it is clicked, formulas are not rendered, but displayed verbatim.

$\endgroup$
  • 7
    $\begingroup$ As far as I can make out, that's only if the address bar contains not the address of the question, but that of something else on the page (usually an answer), cf. epimorphic's answer here. When the URL is the question's, it apparently works (so far I haven't seen that phenomenon then). $\endgroup$ – Daniel Fischer Sep 26 '15 at 13:36
  • $\begingroup$ v2.6.0-beta.1 is out which should fix this. See my updated answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 8:48
12
$\begingroup$

The spacing in eqnarray environments seems to be broken. For instance,

\begin{eqnarray}
1&=&2
\end{eqnarray}

renders as

\begin{eqnarray} 1&=&2 \end{eqnarray}

with the space between the equals sign and the $2$ missing. Here's a screen shot:

screen shot

$\endgroup$
  • $\begingroup$ Actually, the preformatted text also seems to be broken -- all three lines are indented with $4$ spaces and should be displayed without those spaces. $\endgroup$ – joriki Sep 25 '15 at 16:50
  • $\begingroup$ Firefox $40.0.3$ on Mac OS $10.10.3$; user agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0" $\endgroup$ – joriki Sep 25 '15 at 16:52
  • 6
    $\begingroup$ Just a comment to say that eqnarray is very much deprecated in LaTeX. I don't know about MathJaX. $\endgroup$ – Najib Idrissi Sep 25 '15 at 16:54
  • $\begingroup$ I'm pretty sure the code block indent issue is this bug, or some variant of it. $\endgroup$ – Ilmari Karonen Sep 25 '15 at 22:17
  • $\begingroup$ @NajibIdrissi: Thanks, I wasn't aware of that. $\endgroup$ – joriki Sep 25 '15 at 22:48
  • 5
    $\begingroup$ Try writing a true statement. Maybe MathJax 2.6 includes a proof verifier! :P $\endgroup$ – Asaf Karagila Sep 25 '15 at 23:43
  • 1
    $\begingroup$ @joriki, looks like a bug introduced while fixing a different bug. I'll look into it further. Thanks for the bug report. $\endgroup$ – Davide Cervone Sep 26 '15 at 19:30
  • 1
    $\begingroup$ I've created github.com/mathjax/MathJax/issues/1272 to track this. $\endgroup$ – Peter Krautzberger Sep 28 '15 at 8:21
  • $\begingroup$ v2.6.0-beta.1 is out which should fix this. See my updated answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 8:48
10
$\begingroup$

The commutative diagrams produced by AMScd are very bad-looking now:

$$\require{AMScd}
\begin{CD}
A @>>> B \\
@VVV @VVV \\
C @>>> D
\end{CD}$$

gives:

$$\require{AMScd} \begin{CD} A @>>> B \\ @VVV @VVV \\ C @>>> D \end{CD}$$

and here's a screenshot (I'm on Chrome, Windows 10):

screenshot

$\endgroup$
  • $\begingroup$ It's apparently dependent on the resolution too, mine is officially 2160x1440 (well I don't really know the true resolution with all that DPI scaling). $\endgroup$ – Najib Idrissi Sep 28 '15 at 12:15
  • $\begingroup$ Interestingly you see different "steps" depending upon what zoom scale you use, either with Chrome's Zoom or MathJax triggered Zoom option. $\endgroup$ – Mark Hurd Sep 28 '15 at 12:37
  • $\begingroup$ The worst for me is at 150%, where the "steps" actually seem to be discontinuities. $\endgroup$ – Mark Hurd Sep 28 '15 at 12:39
  • $\begingroup$ Thanks for reporting this. Could let me know which output you are using and which browsers you see this on? For the CommonHTML output I can only reproduce such a glitch when changing the browser zoom after rendering (but re-rendering fixes the issue); that might mean it's a browser zoom glitch but we might be able to do something about it anyway. $\endgroup$ – Peter Krautzberger Sep 28 '15 at 13:44
  • $\begingroup$ @PeterKrautzberger I see this in Chrome, Firefox and Edge when I use the CommonHTML output. I didn't touch the zoom setting in any of the three. It is true that depending on the zoom level I see the glitch or not (e.g. I see it at 100%, I don't at 110%, I see it again at 125% etc.) $\endgroup$ – Najib Idrissi Sep 28 '15 at 13:47
  • $\begingroup$ Thanks for the additional information! $\endgroup$ – Peter Krautzberger Sep 28 '15 at 14:42
  • $\begingroup$ @NajibIdrissi, Is this on Windows? If so, what version of Windows? If not, what OS are you using? $\endgroup$ – Davide Cervone Sep 28 '15 at 23:29
  • $\begingroup$ @DavideCervone I'm using WIndows 10. $\endgroup$ – Najib Idrissi Sep 29 '15 at 7:08
  • $\begingroup$ It's actually not a problem with AMScd only, I see the same issue with \xrightarrow, e.g. $\xrightarrow{123456}$ looks bad (similar to the screenshot I posted in the answer). $\endgroup$ – Najib Idrissi Sep 29 '15 at 13:32
  • $\begingroup$ Yes, the issue will be with any horizontally stretched character. I'll see what I can do. $\endgroup$ – Davide Cervone Sep 29 '15 at 20:44
  • $\begingroup$ @NajibIdrissi, if you go to this page, what does it say? $\endgroup$ – Davide Cervone Sep 29 '15 at 20:46
  • $\begingroup$ @NajibIdrissi have you had a chance to check the page Davide linked to? It would tell us if MathJax detects outdated local fonts on your system. $\endgroup$ – Peter Krautzberger Oct 1 '15 at 18:17
  • $\begingroup$ @DavideCervone I'm sorry, I missed the notification. It says "Congratulations, you have the new versions of the MathJax fonts installed on your system. These should work fine with any version of MathJax." I still see the bug (and only on my SP3, not on another computer, so it probably has to do with the resolution and/or scaling). $\endgroup$ – Najib Idrissi Oct 1 '15 at 18:26
  • $\begingroup$ @PeterKrautzberger See above. $\endgroup$ – Najib Idrissi Oct 1 '15 at 18:26
  • $\begingroup$ I've started an issue tracker for this issue, and I believe I have a fix for it. $\endgroup$ – Davide Cervone Oct 3 '15 at 12:33
8
$\begingroup$

The CommonHTML output seems to be slightly smaller than the HTML-CSS output.

HTML-CSS:

enter image description here

CommonHTML:

enter image description here

From this question. I set math scaling to 100% before taking these screenshots.

$\endgroup$
  • $\begingroup$ I'm using Chrome 45.0.2454.99 m on Windows 7. $\endgroup$ – Antonio Vargas Sep 24 '15 at 16:42
  • $\begingroup$ I didn't mean for this to come off as a critique--I just wanted to point out an idiosyncrasy. So far I think I prefer the new CommonHTML rendering to the old HTML-CSS rendering, especially since I haven't seen any of the bugs with square roots that the HTML-CSS rendering has. $\endgroup$ – Antonio Vargas Sep 24 '15 at 16:52
  • 1
    $\begingroup$ No problem. That's a really interesting observation. And thanks for the positive comments! $\endgroup$ – Peter Krautzberger Sep 24 '15 at 17:01
  • 2
    $\begingroup$ This is actually good when it comes to including text in equations; the in-equation text was visibly larger than the normal text (to the point of distracting me personally); now they're much closer to, if not, indistinguishable. $\endgroup$ – pjs36 Sep 24 '15 at 17:19
  • 1
    $\begingroup$ Thanks, @pjs36. MathJax tries to match the x-height of the surrounding font. It sounds like you're seeing improvements there -- which surprises me but might be a side effect of the updated fonts. I'll have to check with our lead dev on that. $\endgroup$ – Peter Krautzberger Sep 24 '15 at 18:26
  • 5
    $\begingroup$ The two output renders use different means of detecting the font size em and ex sizes. The CommonHTML approach should be more reliable, but that is probably the source of the difference. $\endgroup$ – Davide Cervone Sep 24 '15 at 20:12
8
$\begingroup$

When using Common HTML, bad formats display as [Math processing error] for a moment then just disappear. Here's an example:

$\begin{notanenvironment} \notacommnd \end{notanenvironment}$

For me, on Chrome 45.0.2454.101 in Windows 10, HTML-CSS renders with the box as previously.

Note that when I jump to this answer directly, it remains as [Math processing error] (in red). (And when editing this answer the preview remains in this state for seconds -- after rerendering for every keystroke -- then returns to blank as described above, if you wait.)

$\endgroup$
  • 1
    $\begingroup$ Thanks for reporting this bug. I've opened github.com/mathjax/MathJax/issues/1271 $\endgroup$ – Peter Krautzberger Sep 28 '15 at 8:10
  • $\begingroup$ v2.6.0-beta.1 is out which should fix this. See my updated answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 8:49
  • 1
    $\begingroup$ @PeterKrautzberger: While the erroneous LaTeX code is indeed no longer invisible, I assume this is not quite the intended rendering. You can increase the nesting further by running MathJax.Hub.Queue( ["Typeset", MathJax.Hub] ) in the JS console. Probably the content of the error box should be excluded from further MathJax processing. $\endgroup$ – Ilmari Karonen Oct 24 '15 at 11:19
  • $\begingroup$ Definitely not the intended result :-) But I actually can't reproduce this. What browser/OS (version) are you on? $\endgroup$ – Peter Krautzberger Oct 25 '15 at 10:52
  • $\begingroup$ That's what I'm seeing with Chrome 46.0.2490.80 m on Windows 10 (both a 64 bit machine and 32 bit laptop). $\endgroup$ – Mark Hurd Oct 25 '15 at 11:00
  • $\begingroup$ Sorry, I missed your comment, Mark! I can reproduce it now on both Win10 and Linux. I've filed github.com/mathjax/MathJax/issues/1293 to track this. $\endgroup$ – Peter Krautzberger Oct 29 '15 at 10:13
  • $\begingroup$ This is a duplicate of issue 1285, which is already fixed in the develop branch, but not yet included in the beta used by MSE. $\endgroup$ – Davide Cervone Oct 29 '15 at 10:19
5
$\begingroup$

If for whatever reason you want to stick with the older non-beta MathJax version, I have created a workaround.

First, given Mozilla Firefox (might or might not work in other browsers), install the following add-ons:

then restart the browser (if necessary). Now go to AdBlock Filter Preferences (Control-Shift-F) → Custom filters, add new filter group with the Add filter group button, invoke ActionsShow/hide filters (Control-R) near the newly created filter group (if necessary) for the list of the filters in the filter group to show up on the right, and then filter out *beta.mathjax.org/mathjax/latest/MathJax.js* using the Add filter button. Close once you are done. This will kill the new MathJax beta.

Now, to restore functionality, proceed to this Gist and click the Raw button (the top-right corner just above the code). Given your installation of GreaseMonkey is functional, you will be prompted to install the userscript. Proceed, and you are done.

$\endgroup$
  • 1
    $\begingroup$ As I mentioned on the GitHub issue, the crash you see on OS/2 seems related to the AssistiveMML extension's output and a Firefox bug on OS/2. I'm not sure we can do much about that, I'm afraid. $\endgroup$ – Peter Krautzberger Sep 28 '15 at 8:27
  • $\begingroup$ That is fully and entirely okay (after all, we're used to this sort of things here on IBM OS/2) @Peter, I'm very pleased I've heard a comment from a member of the MathJax team (I believe your comment on the GitHub issue ticket precisely addresses the source of the issue which is of a great help to our porter). You are doing a really, really great job! Thank you for all your (and other developers') efforts! $\endgroup$ – dbanet Sep 28 '15 at 22:23
  • $\begingroup$ Note that you can disable the AssitiveMML extension via hidden menu item. If you go to your browser's debug console and enter MathJax.Menu.showAssistiveMML(true), this will enable the hidden menu. Then right-click on any typeset math and select Math Settings->Math Renderer and uncheck AssistiveMML. That should prevent the insertion of MathML into the page that seems to be the source of the issue you are facing. $\endgroup$ – Davide Cervone Sep 28 '15 at 23:35
5
$\begingroup$

With the new Common HTML renderer, \sqrt interacts badly with \frac in inline math (but not in display math). Something like \frac{1}{\sqrt{x}} ($\frac{1}{\sqrt{x}}$) will render like this for me:

screenshot

As you can see, there's no bar above the $x$. It renders fine in display mode (e.g. with dfrac or between double dollars), and the bar is there when the sqrt is outside frac. I'm using Chrome, Windows 10, Common HTML renderer, and I have the latest MathJax fonts according to this page.

$\endgroup$
  • $\begingroup$ We've seen the "disappearing horizontal line" problem before. The line is actually there, but the browser isn't showing it because it thinks it is less than one pixel tall. I'll look into working around it. $\endgroup$ – Davide Cervone Oct 6 '15 at 10:30
  • $\begingroup$ I've started an issue tracker for this report. $\endgroup$ – Davide Cervone Oct 6 '15 at 23:29
  • $\begingroup$ v2.6.0-beta.1 is out which should fix this. See my updated answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 8:49
  • $\begingroup$ @PeterKrautzberger Is the fix deployed yet? At this point I'm certain the cache of my browser is empty etc., but I still have the issue. (And also for the other bug I reported.) $\endgroup$ – Najib Idrissi Oct 12 '15 at 9:43
  • $\begingroup$ @NajibIdrissi, did you restart the browser? Just clearing the cache is not enough for Chrome. If you use the MathJax contextual menu to open the "About MathJax" dialog, make sure that the CommonHTML output jax is listed as version 2.6.0-beta.1 (not just 2.6.0-beta). It does look like this overline issue still isn't fixed completely, but the stretchy arrows should be fixed (or at least improved). $\endgroup$ – Davide Cervone Oct 12 '15 at 11:16
  • $\begingroup$ @DavideCervone Yes, I restarted and everything (even waited a few days in case it was still cached in the CDN). I do see "CommonHTML Output Jax v2.6.0-beta.1" in the "About" popup. The overline is not fixed at 100% zoom (it does show when I start zooming), and neither are the stretchy arrows. Again, it only happens on my SP3 - the scaling is probably to blame here. $\endgroup$ – Najib Idrissi Oct 12 '15 at 11:43
  • $\begingroup$ @NajibIdrissi, yes, I know the overline issue isn't resolved, but the arrows should be improved. I have been testing in Windows 7, however, so I will have to try Windows 10 and see if there is a difference. $\endgroup$ – Davide Cervone Oct 12 '15 at 12:10
  • $\begingroup$ @NajibIdrissi, I just tried Chrome on Windows 10 evaluation VM (no service pack), and the arrows worked fine for me at 100% zoom. Not sure what to tell you. Scaling certainly can affect this, and it would not surprise me if some zoom levels showed the one pixel offset. $\endgroup$ – Davide Cervone Oct 12 '15 at 12:36
  • $\begingroup$ @DavideCervone There's this feature in Windows 8+ (I think) where the display is scaled on high-DPI screens. Something like "Make all text bigger by 150%". I suspect that's the cause... $\endgroup$ – Najib Idrissi Oct 12 '15 at 12:53
  • $\begingroup$ @NajibIdrissi, that sounds like it would do it. Thanks for the pointer. The CommonHTML output uses transform CSS to stretch the extender character to form the stretched vertical and horizontal characters (rather than repeated copies of the extender as in HTML-CSS output). That is more efficient, but it turns out to be more fragile than I had hoped (your issue as well as some others). We may have to go back to repeated characters, which should clear up the alignment problem (I hope). $\endgroup$ – Davide Cervone Oct 12 '15 at 23:25
  • $\begingroup$ v2.6.0-beta.2 is out which should fix this. See also my updated answer. $\endgroup$ – Peter Krautzberger Dec 15 '15 at 11:50
4
$\begingroup$

As Najib Idrissi notes in the comments, the outlines for focused links that contain MathJax seem to be a bit messed up in Chrome. Sure, it looks OK now when the focus is on the MathJax element itself:

Screenshot of focused MathJax element in a link on Chrome using HTML-CSS renderer

but when you Shift+Tab back to focus on the link that contains the MathJax, it looks like this (Chrome 45.0.2454.101, 64-bit, Ubuntu Linux):

Screenshot of MathJax element in a focused link on Chrome using HTML-CSS renderer

I don't think this is really how it's supposed to look, is it?


Edit: Oops, I forgot that I wasn't on my home computer, and that I was using the old HTML-CSS renderer. With the new CommonHTML renderer, things are a bit better (but also, in some ways, a bit worse):

Screenshot of focused MathJax element in a link on Chrome using CommonHTML renderer

Screenshot of MathJax element in a focused link on Chrome using CommonHTML renderer]

I suppose that's good enough to live with.

$\endgroup$
  • $\begingroup$ I think this is a browser bug (or at least "odd behavior") caused by the clipping used by the HTML-CSS output. It shouldn't happen with the CommonHTML and SVG output since they don't use clipping. I'm not sure we can do much about it but we'll check. $\endgroup$ – Peter Krautzberger Oct 1 '15 at 18:26
  • $\begingroup$ @PeterKrautzberger: Ah, I forgot I was still using the HTML-CSS renderer on this computer. With CommonHTML, it's not nearly as bad (although the focus-on-math-element case is slightly worse). $\endgroup$ – Ilmari Karonen Oct 1 '15 at 18:34
  • $\begingroup$ Peter is correct, this is due to the clipping doesn't seem to be taken into account when the browser determines the focus outline. Because of this, MathJax overrides the focus highlighting for the HTML-CSS output, but that only affects the case when the focus is on the math element itself, not on some element containing the math. I don't think we can do anything about that case. In terms of the CommonHTML output, what do you think the result should look like? It might be possible to smooth out the top, but I think it will always be larger that then rest of the link in the second case. $\endgroup$ – Davide Cervone Oct 3 '15 at 12:41
  • $\begingroup$ @DavideCervone: I'm not sure, but either the way it looks in Firefox (an even-height box around the whole link) or the way it currently looks in Chrome with the SVG renderer (a thin box around the link text, with a single "bump" around the math formula) would be OK. But even the current appearance with CommonHTML isn't bad (the way it is with HTML-CSS), just a little bit ugly and uneven. $\endgroup$ – Ilmari Karonen Oct 3 '15 at 13:04
  • $\begingroup$ @IlmariKaronen, the handling of the outline is browser-specific, with Firefox seeming to make a rectangular box that surrounds all the content, while WebKit (Chrome, Safari, Opera) uses a tighter outline that is the union of the bounding boxes for the individual visible elements of the selected item. I don't think there is anything MathJax can do anything about the WebKit outline. MathJax already has the math enclosed in a box of the correct size, but WebKit ignores that and seems to go to the text elements inside it directly. $\endgroup$ – Davide Cervone Oct 4 '15 at 16:17
  • $\begingroup$ @DavideCervone: It might be possible to hack it with CSS. Based on a very quick test, .mjx-chtml { display: inline-table } seems to make the outline on MathJax CommonHTML elements nice and rectangular, with no immediately obvious negative side-effects. That said, I haven't done any thorough testing on this yet, and there might well be a better way to achieve the same result. $\endgroup$ – Ilmari Karonen Oct 4 '15 at 16:55
  • $\begingroup$ @IlmariKaronen, that will definitely have ill effects in some circumstances, but it is something to consider further. $\endgroup$ – Davide Cervone Oct 4 '15 at 17:54
  • $\begingroup$ I started a MathJax issue tracker for this report. $\endgroup$ – Davide Cervone Oct 6 '15 at 23:34
  • $\begingroup$ v2.6.0-beta.1 is out which should improve this. See my updated answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 8:49
4
$\begingroup$

I'm seeing vertical alignment differences between CommonHTML and HTML-CSS, using Safari 9.0 on Yosemite. The following images are pulled from this question.

Here's Common HTML:enter image description here

Here's HTML-CSS:enter image description here

Interestingly, the vertical bar actually looks better with Common HTML!

$\endgroup$
  • 1
    $\begingroup$ The "$dt$", however, looks worse with CommonHTML. $\endgroup$ – Najib Idrissi Oct 7 '15 at 17:30
  • $\begingroup$ Well, most of it looks worse, actually. The $dt$ suffers from the same vertical alignment issues. But that is to be expected, as it's still a work in progress. $\endgroup$ – Michael Grant Oct 7 '15 at 18:16
  • $\begingroup$ I just confirmed the same result on El Capitan. $\endgroup$ – Michael Grant Oct 7 '15 at 18:17
  • $\begingroup$ Thanks for reporting. We'll look into it. Could you visit our fonts test page to rule out outdated local fonts? Please note that (besides the issues) there are different fonts at work here; HTML-CSS uses the STIX fonts installed by Safari while CommonHTML uses the MathJax TeX fonts (since we do not support STIX for it yet); see also my answer for more information. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 9:01
  • $\begingroup$ I've opened github.com/mathjax/MathJax/issues/1283 to track this. $\endgroup$ – Peter Krautzberger Oct 9 '15 at 9:02
  • $\begingroup$ Sorry, I never saw you comment for some reason. I will try and follow up this weekend. $\endgroup$ – Michael Grant Oct 10 '15 at 12:25
  • $\begingroup$ v2.6.0-beta.2 is out which should see improvements in this. See also Peter's updated answer. $\endgroup$ – Davide Cervone Dec 15 '15 at 16:08
  • $\begingroup$ The "$n\to\infty$' also looks worse with common HTML, for the $n$ is misplaced. The $a$ and $s$ are also misplaced compared to each other, and so is the $2$ and $e$ when side-by-side. Maybe for the vertical bar, instead of $ \ \ $ \bigg|_0^n $ \ \ $, maybe you can do $ \ \ $ \bigg|_{\, 0}^{\, n} $ \ \ $. $\endgroup$ – Mr Pie Mar 2 '18 at 13:00
4
$\begingroup$

The spacing in this formula is very odd: $$\prod_{r=2}^{N}\frac{\Gamma^2(r\alpha+‎1‎‎)}{\Gamma((r-1)\alpha+‎1‎‎)\Gamma((r+1)\alpha+‎1‎‎)}<1$$

(Found in Properties of the Gamma function)

In case others aren't seeing the same thing: this is what it looks like for me (OS X, Safari, HTML-CSS renderer):

enter image description here

With HTML-Common, it looks a bit better, but there is still spurious spaces before the closing parentheses.

$\endgroup$
  • $\begingroup$ There appears to be some special Unicode characters in that formula, in particular instances of U+200E: LEFT-TO-RIGHT MARK. If you get rid of these, it seems to return to normal: $$\prod_{r=2}^{N}\frac{\Gamma^2(r\alpha+1)}{\Gamma((r-1)\alpha+1) \Gamma((r+1)\alpha+1)}<1$$ $\endgroup$ – user642796 Oct 12 '15 at 9:37
  • 1
    $\begingroup$ This is how the CommonHTML output looks for me. I wouldn't necessarily call that "better". $\endgroup$ – Daniel Fischer Oct 12 '15 at 9:49
  • $\begingroup$ @ArthurFischer You're right. I should probably have checked for that. (But it would be nice if MathJax filtered unprintable Unicode characters away.) $\endgroup$ – mrf Oct 12 '15 at 9:53
  • $\begingroup$ @DanielFischer, that is also due to the invisible characters. If they are removed, your rendering should be formatted more normally. $\endgroup$ – Davide Cervone Oct 12 '15 at 11:12
  • $\begingroup$ @DavideCervone I know. And it indeed renders normally with them removed. I just wanted to document in which way the ltr characters screw up the CommonHTML rendering here, since it may be a different way for mrf. $\endgroup$ – Daniel Fischer Oct 12 '15 at 11:20
  • $\begingroup$ @DanielFischer, Got it. Thanks. $\endgroup$ – Davide Cervone Oct 12 '15 at 11:23
4
$\begingroup$

When using Common HTML rendering, the math in the answer on this page shows $\color{red}{\textit{[Math Processing Error]}}$ for a moment then disappears. When using HTML-CSS it renders fine.

I've tried clearing my cache and cookies but the problem persists.

Chrome 46.0.2490.71 m, Mathjax v2.6.0-beta.1 using local (updated) TeX fonts


The problem seems to be with the \big, \bigg, \bigr, \biggr, etc. commands, then adding both a subscript and a superscript to the item that was embiggened.

For example:

$$
\left[ x^{x^{x^{x^{x^x}}}} \right]_{x=1}^{\infty}
$$

$$ \left[ x^{x^{x^{x^{x^x}}}} \right]_{x=1}^{\infty} $$

works fine, but neither

$$
\biggl[ x^{x^{x^{x^{x^x}}}} \biggr]_{x=1}^{\infty}
$$

$$ \biggl[ x^{x^{x^{x^{x^x}}}} \biggr]_{x=1}^{\infty} $$

nor

$$
\bigg[ x^{x^{x^{x^{x^x}}}} \bigg]_{x=1}^{\infty}
$$

$$ \bigg[ x^{x^{x^{x^{x^x}}}} \bigg]_{x=1}^{\infty} $$

work for me when using Common HTML. When using HTML-CSS they all render fine and look the same.

$\endgroup$
  • 2
    $\begingroup$ This is being tracked by this MathJax issue, as you know. It is easily fixed. Thanks for reporting. $\endgroup$ – Davide Cervone Oct 18 '15 at 11:30
  • $\begingroup$ v2.6.0-beta.2 is out which should fix this. See also Peter's updated answer. $\endgroup$ – Davide Cervone Dec 15 '15 at 16:07
3
$\begingroup$

I didn't know about this until less than a minute ago, but some days ago I noticed a conspicuous abrupt change for the worse in the behavior of MathJax on math.stackexchange.com. I frequently see unrendered code, even after repeatedly reloading the page. Sometimes while editing an answer I see my code rather than the mathematical notation one is supposed to see. Formerly that was always fixed by reloading the page. That frequently no longer works.

I am one of the most prolific contributors to m.s.e. and accordingly I have more opportunity to observe what is happening than most others do.

$\endgroup$
  • 2
    $\begingroup$ As Daniel Fischer commented under your question, "If you have a specific bug that's not yet reported, please report it [here]." Your issue sounds exactly like the one I reported more than a week ago in this thread. If your issue is different, please differentiate your answer accordingly. $\endgroup$ – epimorphic Oct 3 '15 at 21:56
  • 1
    $\begingroup$ Work-around: having saved an answer draft without it rendering the Latex, if i then click on the question title and so refresh the entire question, it then shows my Latex correctly $\endgroup$ – Will Jagy Oct 3 '15 at 22:05
3
$\begingroup$

When using the HTML-CSS renderer long math expressions are automatically wrapped. With CommonHTML they overflow out of their element.

Example:

$$\int_{-\infty}^{\infty} \frac{e^{-t^2}}{t-z}\,dt = \int_{|t-x| < s(z,x)} \frac{e^{-t^2} - e^{-x^2}}{t-z}\,dt + \int_{s(z,x) < |t-x|}  \frac{e^{-t^2}}{t-z}\,dt - i\pi e^{-x^2} - e^{-x^2} \int_{s(z,x) < |t-x|} \left( \frac{1}{t-z} - \frac{1}{t-x} \right) \,dt$$

$$\int_{-\infty}^{\infty} \frac{e^{-t^2}}{t-z}\,dt = \int_{|t-x| < s(z,x)} \frac{e^{-t^2} - e^{-x^2}}{t-z}\,dt + \int_{s(z,x) < |t-x|} \frac{e^{-t^2}}{t-z}\,dt - i\pi e^{-x^2} - e^{-x^2} \int_{s(z,x) < |t-x|} \left( \frac{1}{t-z} - \frac{1}{t-x} \right) \,dt$$

$\endgroup$
  • $\begingroup$ I've opened an issue for this on GitHub $\endgroup$ – Antonio Vargas Oct 19 '15 at 2:17
  • $\begingroup$ Thanks for reporting this here and on our issue tracker. It seems to be a configuration issue on math.SE. The configuration only sets up line-breaking for the HTML-CSS output -- you'll notice that the SVG output also does not line-break. $\endgroup$ – Peter Krautzberger Oct 19 '15 at 8:01
  • $\begingroup$ Thanks for the tip @Peter, it looks like the SE team just needs to also pass "CommonHTML": { preferredFont: "TeX", availableFonts: ["STIX","TeX"], linebreaks: { automatic:true }, EqnChunk: (MathJax.Hub.Browser.isMobile ? 10 : 50) } to MathJax.Hub.Config (and the analogous one for SVG rendering, etc.). Doing this on my end has solved the problem. $\endgroup$ – Antonio Vargas Oct 29 '15 at 17:21
  • $\begingroup$ Yes, and probably something for the SVG output too $\endgroup$ – Peter Krautzberger Oct 29 '15 at 17:23
3
$\begingroup$

With the new version from yesterday, I'm seeing some spacing problems. In the first screenshot there is reduced spacing.

enter image description here

If I right-click on a link on the page the spacing suddenly appears correctly, as in this second screenshot. The same even if I just click on some of the whitespace areas on the page, it corrects it. Then clicking elsewhere, it reverts to being wrong again.

It's happening with questions, answers and comments.

enter image description here

I've cleared cache and installed fonts to no avail. I'm not seeing the problem on MathOverflow or CrossValidated.

Would you be able to look into it?

Thanks

EDIT: added screenshots:

About MathJax:

enter image description here

About Internet Explorer:

enter image description here

Message from the CodePen web page is:

Congratulations, you have the new versions of the MathJax fonts installed on your system. These should work fine with any version of MathJax.

$\endgroup$
  • 1
    $\begingroup$ Thanks for raising this. I'm not able to reproduce this. Which output are you using? Also, which browser and OS version are you seeing this on? Finally, what does the about (right/cmd-click => Menu =>About MathJax) say at the top regarding fonts? And in case it's TeX fonts, what does codepen.io/mathjax/full/avZRzM say? $\endgroup$ – Peter Krautzberger Dec 17 '15 at 10:19
  • 1
    $\begingroup$ Oh, and some browsers (e.g., Chrome) need to restart to clear the cache for sure. $\endgroup$ – Peter Krautzberger Dec 17 '15 at 10:19
  • $\begingroup$ @PeterKrautzberger Thanks for the quick response. I've added some info to my answer. The OS is Windows 7 SP1 Home Premium. I've cleared cache and rebooted my PC but it's still the same. I don't know what you mean by "What output are you using?". $\endgroup$ – Mick A Dec 17 '15 at 10:59
  • $\begingroup$ @PeterKrautzberger If you mean Math Settings -> Math Renderer, it is set to HTML-CSS. $\endgroup$ – Mick A Dec 17 '15 at 11:16
  • 2
    $\begingroup$ I can reproduce, and know what the source is. I will look into how to resolve it. I've opened an issue tracker for the problem, which includes some explanation of what is going on. $\endgroup$ – Davide Cervone Dec 17 '15 at 11:51
  • $\begingroup$ @DavideCervone Many thanks for the help. $\endgroup$ – Mick A Dec 17 '15 at 11:56
2
$\begingroup$

While not exactly a beta issue, I think this is a good place to put the wish that double lines in arrays work (they don't need to reproduce the $\rm\LaTeX$ result perfectly — the latter not being optimal anyway —, but it should definitely show a difference between single and double lines).

$\endgroup$
  • $\begingroup$ You should post this as a feature request on the MathJax issue tracker. $\endgroup$ – Davide Cervone Oct 6 '15 at 10:29
  • $\begingroup$ @DavideCervone: Done. $\endgroup$ – celtschk Oct 10 '15 at 10:41
  • $\begingroup$ Thanks. We'll use that for further correspondence on this issue. $\endgroup$ – Davide Cervone Oct 10 '15 at 14:41

You must log in to answer this question.

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