37
$\begingroup$

We have deployed the latest Mathjax 2.5 alpha 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 particular release has a new feature that we need your help testing. Here's a direct quote from Davide Cervone & Peter Krautzberger from the MathJax team:

We are hoping to get feedback on one specific new feature: the "Fast preview" rendering mode.

This is an opt-in test.

You can activate the Fast Preview mode via the MathJax menu:

$$X^2 ---------------------------- X^2$$

right/cmd click an equation such as the one above => 
    click Math Settings => 
    click Math Renderer => 
    check "Fast Preview".  (Not "Fast HTML"; see below.)

This mode works as follows:

  1. the new Fast HTML output creates a fast-but-rough preview
  2. the HTML-CSS output runs and replaces the preview (or the SVG if you've switched manually)

[Note that the "Fast HTML" entry in the renderer list is the output format used by the fast preview temporarily before the output is replaced by the higher-quality output that MathJax normally produces. If you select "Fast HTML" in the renderer list, that will keep the fast output permanently, rather than replacing it with the better version. You can use that to see what the faster output look like. We are working on improving the quality of this output, but those improvements won't come until after v2.5 is released. We hope Fast HTML will be able to replace HTML-CSS in the future.]

There are a couple of variables we are hoping to tweak thanks to your feedback. Our main questions are:

a) Would you prefer the second run to show equations incrementally?

Right now, the second run will finish rendering all equations before replacing the Fast-HTML previews. This reduces jitter and speeds up the second run. It can be configured to show equations one-by-one or in chunks (e.g., 50, then 100 more, then 200 more).

b) how responsive is your browser during the second run?

Right now, the second run is optimized to keep your browser very responsive; this prolongs the second run slightly and can be tweaked in either direction.

These are questions of balancing the two runs and we hope your feedback here will allow us to strike the right balance.

Thanks again for your help!

$\endgroup$
  • 19
    $\begingroup$ Thanks to the Stack Exchange team for helping us at MathJax and thanks to the community for any feedback! $\endgroup$ – Peter Krautzberger Dec 3 '14 at 13:43
  • 2
    $\begingroup$ Just to confirm: one does not have to choose "Fast HTML" renderer in order for "Fast preview" to be active, is this correct? $\endgroup$ – user147263 Dec 3 '14 at 14:07
  • 1
    $\begingroup$ @Raff, Correct. "Fast Preview" will use the fast output temporarily as the page is loaded, and replace the results with the usual MathJax output after it has been processed (behind the scenes) more slowly. This gives you fast but less polished math until the better version is available. If you select "Fast HTML", then the fast math is left in place permanently (you are selecting that as your renderer rather than the higher quality HTML-CSS or SVG output). $\endgroup$ – Davide Cervone Dec 3 '14 at 14:10
  • $\begingroup$ @Raff no. The preview works with the other outputs (HTML-CSS and SVG). If you select the "Fast HTML" output, you would only get the first quick&dirty run. That new output is not yet finished which is why it is currently designed as a preview (e.g., it doesn't use webfonts); we plan to bring it up to quality in the release after. EDIT: Davide beat me to it ;-) $\endgroup$ – Peter Krautzberger Dec 3 '14 at 14:12
  • 2
    $\begingroup$ Great! I reckoned a search in Ron Gordon's posting history was a good strategy to find a MathJax heavy answer, and here it is if you want to try out the new rendering feature. There might be heavier posts out there and whoever finds one can feel free to add a link as a comment here. $\endgroup$ – Daniel R Dec 3 '14 at 16:31
  • $\begingroup$ @DanielR I'll try to reproduce this. Which Chrome version? $\endgroup$ – Peter Krautzberger Dec 3 '14 at 16:46
  • $\begingroup$ @PeterKrautzberger Version 33.0.1750.146 $\endgroup$ – Daniel R Dec 3 '14 at 16:46
  • 3
    $\begingroup$ This page also has a lot of mathjax, if someone is interested. $\endgroup$ – Najib Idrissi Dec 3 '14 at 17:05
  • $\begingroup$ @DanielR hm. I failed to reproduce this (see saucelabs.com/tests/c7d8bd692591465aa27f10888033bbfe). It sounds like the pre-processor runs into trouble. Do you get any errors in the developer console? Does a page refresh, navigating away, or a change of output renderer fix it? $\endgroup$ – Peter Krautzberger Dec 3 '14 at 17:06
  • 1
    $\begingroup$ Oh, thanks for the feedback -- that's relief :D no need to delete from my end -- perhaps we should clarify the text of the OP? $\endgroup$ – Peter Krautzberger Dec 3 '14 at 17:14
  • 3
    $\begingroup$ It seems that the renderer setting is set for meta site and the main site separately. So, changing the renderer option using the formula in the post will not change it on the main site, which is where the actual testing needs to be done. $\endgroup$ – user147263 Dec 3 '14 at 17:52
  • 3
    $\begingroup$ Perhaps the ol' "Limits catalog" by our friend The @Raff is a suitable MathJax monster. (And indeed it is not for those with a timid CPU and RAM restrictions.) It's your computer's funeral. $\endgroup$ – Asaf Karagila Dec 3 '14 at 19:25
  • 4
    $\begingroup$ Wow. I tested the limits catalog, and the fast preview was indeed fast. The browser remained responsive, and only had about one second where it was hanging, then the HTML-CSS output appeared and it was fairly smooth. (Intel Q9550, 4gb RAM, Linux 3.17.4 64bit, Firefox 34.0.5) $\endgroup$ – Asaf Karagila Dec 3 '14 at 19:28
  • 1
    $\begingroup$ 1) Can you prioritize formulae currently shown? The rest can be rendered in the background or even lazily. (Lazy would also solve the skipping problem.) 2) I notice (with the limits list) that you torture one CPU pretty hard while the others idle. Make use of multi-cores which most modern systems have; rendering formulae should almost always be embarrassingly parallelisable. (Might have to filter out newcommand and such, but still.) $\endgroup$ – Raphael Dec 11 '14 at 14:21
  • 4
    $\begingroup$ @Raphael JavaScript is single-threaded. The only way around this would be webworkers but that's not really feasible for MathJax right now (see this SO answer for some aspects). $\endgroup$ – Peter Krautzberger Dec 15 '14 at 8:53
6
$\begingroup$

Not sure if this is new in 2.5, but: I'm seeing a lack of spacing before the aligned symbol in the aligned environment. Tested in Firefox 33 and 35 and Safari 8 on OS X 10.10.

Here is a sample: $$\begin{aligned} u_t-u_{xx} &= p(x,t) \\ u(x,0) &= 0 \end{aligned}$$

Compare with the same code, wrapped in the similar align environment: $$\begin{align} u_t-u_{xx} &= p(x,t) \\ u(x,0) &= 0 \end{align}$$

Screenshot:

$\endgroup$
  • $\begingroup$ Thanks for the detailed report. I'll look into it. I think it is due to a change in 2.4, but should be fixed. $\endgroup$ – Davide Cervone Dec 17 '14 at 20:37
  • 1
    $\begingroup$ I've added an issue tracker for the problem $\endgroup$ – Davide Cervone Dec 19 '14 at 18:55
  • $\begingroup$ @DavideCervone That is not an issue. aligned shouldn't be used in replace of align which offers the spacing. One generally uses aligned inside of align. Here is the information on aligned. That is, the environment is working how it is intended. tex.stackexchange.com/questions/111891/… $\endgroup$ – dustin Dec 20 '14 at 21:18
  • $\begingroup$ @dustin How do you propose to type up the following with align? $$\left\{\begin{aligned} u_t-u_{xx} &= p(x,t) \\ u(x,0) &= 0 \end{aligned}\right.$$ $\endgroup$ – epimorphic Dec 20 '14 at 21:28
  • $\begingroup$ Like so $$\begin{cases} u_t - u_{xx} &= p(x,t)\\ u(x,0) &= 0\end{cases}$$ The cases environment is made for that. $\endgroup$ – dustin Dec 20 '14 at 21:29
  • $\begingroup$ @dustin That looks rather awful. $\endgroup$ – epimorphic Dec 20 '14 at 21:30
  • $\begingroup$ You can redefine the environment as you need but there is an environment to achieve that look. $\endgroup$ – dustin Dec 20 '14 at 21:31
  • $\begingroup$ Or you can use array with rcl. There are literally numerous options. If you want to get into specifics, ask on TeX.SX. $\endgroup$ – dustin Dec 20 '14 at 21:33
  • $\begingroup$ case alignment options here you go asked and answered with how to align to the right. Of course, you will need to adapt it to your specific need but the info is there. $\endgroup$ – dustin Dec 20 '14 at 21:35
  • $\begingroup$ @dustin Or we could have the aligned environment fixed, since it's one of the environments that MathJax supports officially, and has been used by plenty of other users on this site. The uses of align and aligned are different, so I rather resent your downvote. $\endgroup$ – epimorphic Dec 20 '14 at 21:37
  • $\begingroup$ That isn't fixing the environment. It is working properly. You received the down vote because there is nothing wrong with the environment it is working as intended. $\endgroup$ – dustin Dec 20 '14 at 21:38
  • 1
    $\begingroup$ @dustin No it's not. Compare with the output of the same code in LaTeX. $\endgroup$ – epimorphic Dec 20 '14 at 21:39
  • $\begingroup$ All I can say is check out the LaTeX documentation on the amsmath package. You will find the definition of aligned and you will see it isn't broken. It is doing what it is supposed to do. $\endgroup$ – dustin Dec 20 '14 at 21:40
  • 1
    $\begingroup$ @dustin, I believe that epimorphic is correct, and that the link you cited actually shows that. It says "a trick adjusts things so that x&=y gives the right spacing around the equals sign", which is not currently happening in MathJax. Epimorphic's example shows that, and I have confirmed it in the code. He is correct that LaTeX does include this space, and it is a bug in MathJax. I have a fix for it and will be applying it to the next version of MathJax. $\endgroup$ – Davide Cervone Dec 20 '14 at 22:33
  • 1
    $\begingroup$ @Dustin, the issue has nothing to do with whether it is used alone on in another environment. MathJax handles it the same in both cases, and the lack of space before the equal sign has nothing to do with whether it is used in another environment or not. Trust me, I wrote the code. Epimophic is correct that the spacing in MathJax is wrong and needs to be fixed. You are correct that aligned does belong inside another environment, but MathJax is not that strict about it. Believe me, that has nothing to do with the spacing issue. $\endgroup$ – Davide Cervone Dec 20 '14 at 23:16
3
$\begingroup$

Double vertical bars \| \|, typically used as the norm notation, render slanted by the Fast HTML renderer. For example, $\|R(f)-R(g)\|\le \|f-g\|$ becomes

bars

I understand the fonts are rough but this looks like a wrong character altogether.

Single vertical bars are not affected.

$\endgroup$
  • 2
    $\begingroup$ The Fast HTML output doesn't currently use web fonts, so it relies on the fonts on your system. It requests Times, but unfortunately, this font doesn't include many math symbols, and the double vertical bar is one. So it takes that from other font on your system. Unfortunately, fonts don't seem to agree on whether this character should be vertical or slanted. Currently, MathJax used U+2225 (parallel to), and perhaps that should be U+2016 instead, but even that is not uniformly treated as vertical lines. Once we start to use web fonts for Fast HTML, this will be taken care of. $\endgroup$ – Davide Cervone Dec 20 '14 at 23:34
3
$\begingroup$

Numbered equations have numbers on the left in the Fast HTML output:

fast

unlike the HTML-CSS output:

final

Also, the number is very close to the equation itself, despite there being plenty of room on the line. Seen here.

$\endgroup$
  • $\begingroup$ The Fast HTML output doesn't yet implement the <mlabeledtr> MathML element (for a labeled table row) that is used for equation numbers. I have modified the Fast HTML output to remove the label rather than place it incorrectly (it was also causing the table columns to misalign). Again, the Fast HTML is not feature-complete at this point, and we will be expanding and improving it in the future. That's why we are using it only as a preview for now. $\endgroup$ – Davide Cervone Dec 31 '14 at 20:15

You must log in to answer this question.

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