Wow, that was fast, thanks so much!
One thing to consider. KaTex still lacks certain features as compared to MathJax. In Khan Academy, they actually fallback to MathJax when KaTeX fails. This would probably make sense to implement once the server-side rendering is in place, cause otherwise you’d always need to ship both Katex and mathjax, which is likely undesirable.
How do you make the decision when to fall back? Curious, can this also be decided on the client?
I am not actually involved directly, but my guess would be simply when KaTex throws an error they use MathJax?
And I am pretty sure they do it on the client as well.
For more info I’d suggest asking them directly on their github.
Really useful plugin.
I noticed an issue that when I try to print a page, the printed version doesn’t render the math at all. Can rendering support be enabled for print layout as well?
There are a couple of ways to print - via the browser menu or via the keyboard shortcut ctrl-p. When you use the keyboard shortcut, the keyboard event is captured by the Discourse App which creates a printer friendly version of the topic and sends that to the printer. One advantage is that this allows the user to print out long topics, as discussed over in this topic.
A workaround is to use the browser menu. At least this seems to work for short topics on my computer setups.
@maja has been working on a pretty cool plugin for Graphviz support, with it we create PNGs instead of rendering using JS so it ends up being printer and email friendly.
The downside of this kind of approach with MathJax is that some people want the accessibility right click stuff on formulas, however we could either:
Allow for SVG based rendering in posts (PNG in email): on right click do magic to swap with a JS based render. (ultra hard mode)
Allow for PNG in posts + email: on right click do magic to swap with a JS based render. (ultra hard mode)
Leave as is and switch to PNG based rendering for email and print, add a site setting so people can just do PNG everywhere if they want. (medium difficulty)
And a bunch of permutations of the above options.
My vote would be just to start with fixing print and email cause it is now totally broken, then we can think about stepping away from JS based rendering in normal usage (if we can figure out how to keep accessibility).
That does sound interesting - I used to use Graphviz quite a bit. I guess the idea is that you just type in Graphviz code and a PNG is rendered server side - cool! Is there a plugin site on GitHub?
So, you’re suggesting that rendering server side images fixes this problem? Maybe it would fix this one, as well. That would be nice.
Hold tight we will make an announcement on meta in the next few days and @maja will ping you! Really happy to have you around to test the graphviz plugin!
Not sure … I think that is an unrelated problem.
Super! I’m sure I’d use it on my site.
I’m saying that if the math were rendered server-side, then the cooked version of the post wouldn’t need MathJax at all since it would just point to a PNG or SVG image. Thus printing and email problems are magically fixed.
MathJax V3 recently came out in Beta, by the way, and it’s clear that they hope to improve server side support. I don’t know for sure but I would guess they’d do some things to improve the accessibility issues in that context.
I wonder how the PR from @jks for server-side HTML rendering relates to this discussion. This would fix the print and possibly email issue as well, wouldn’t it?
That’s literally labelled “Proof-of-concept”. So I doubt that it’s ready for production. The latest 2.7.* versions of MathJax aren’t ES6 so they aren’t easy to use with Node. I really anticipate the MathJax V3 to be a great improvement in this direction and recommend using that. It is beta, so development can begin.
Yeah, it’s going to need some more work before I’d run it in production, such as how to fall back to client-side rendering if the node process fails and how to install the npm dependencies when setting up the extension and keep them updated. The output size (in terms of bytes or DOM nodes) was pretty big for even simple formulas, so I wonder if there are any simple optimizations we could do. I don’t think I noticed any issues related to ES6 support, though.
Just FYI: Did a bit of testing with the Katex PR. One very nice thing is that the preview in the composer does not flicker at all during editing.