by uuuuuuuuuuuu on 6/27/21, 11:27 PM with 85 comments
by kisonecat on 6/28/21, 12:16 AM
To make it relatively fast, the TeX engine gets snapshotted and shipped to the browser with much of TeXlive already loaded. So even things like TikZ work reasonably well. There is of course a lot more to do! The plan is to convert ximera.osu.edu to this new backend by the fall.
by joppy on 6/28/21, 1:51 AM
On the flip side, I have reverted some of my server-side rendering of mathematics back to client-side rendering, because of considerations like webpage size. On mathematics-heavy pages, I found that pages that would otherwise be about 50KB in size got inflated up to about 1MB after server-side rendering all of the mathematics. After compression the difference was more like 70K, but this difference is the entire size of the (compressed) KaTeX library. I think it is completely reasonable to only transmit LaTeX markup over the wire, and have a client-side library take care of the presentation (as we do for HTML, SVG, ...).
I've also investigated MathML, but cross-browser support is terrible and has been for years. You also still get the size explosion problem, because LaTeX markup is just so much more compact than whatever MathML soup is equivalent.
[1]: https://katex.org/
by daymi on 6/28/21, 12:54 AM
The correct fix is to have MathML natively on all browsers (no JS)--and Igalia is working on that: https://mathml.igalia.com/faq/
by prezjordan on 6/28/21, 12:53 AM
MathJax does not support this because, IIRC, it runs layout calculations in the browser whereas KaTeX passes it off to CSS.
If your argument is then that layout calculations should _also_ happen on the server then... I'm not sold and that would be a critique of web browsers and not math rendering.
by crazygringo on 6/28/21, 12:44 AM
Rendering equations client-side doesn't seem absurd to me. All of HTML and CSS and SVG is rendered client-side, why shouldn't equations be too?
I'm completely unclear why the author thinks equations specifically should be rendered server-side. Do they think HTML pages should be delivered as prerendered images or SVG's too...? Because it seems like the philosophy would apply the same way.
by TheRealPomax on 6/28/21, 4:48 AM
And no, MathML is irrelevant: you don't care about MathML, and your users don't care about MathML: all you care about is that users can read your formulae, and all your users care about is that they see decent-looking maths. As much as I like the idea of MathML, there is simply no reason to ever use it. Nothing is mining the web for maths, and semantic markup for maths buys you nothing.
You have a build system (because your content is generated from markdown or the like. No one who wants to deploy a real site writes pure HTML in 2021), make that generate SVG images by literally just running LaTeX during your build, to replace all your maths with SVG <img> code instead. Because why would you even bother with MathJax or KaTeX, they put the burden on your users, which is ridiculous: you're building your content already, just build static content for your formulae)
And sure, does your site have maybe 10 formulae? By all means, use MathJax or KaTeX. But if it relies on maths, generate your graphics offline using actual LaTeX (and this is trivial using github actions[3]) and use <img> elements that point to those SVG images.
(I run my maths through xelatex, then losslessly convert the resulting PDF to SVG by first cropping the PDF, then running pdf2svg[2]. Is that a lot of work? No, it is not. It's a one-time setup and it simply runs whenever content gets updated. It's about as no-effort as it gets)
[1] https://pomax.github.io/bezierinfo
[2] https://github.com/Pomax/BezierInfo-2/blob/master/src/build/...
[3] https://github.com/Pomax/BezierInfo-2/blob/master/.github/wo...
by neolog on 6/28/21, 12:46 AM
by vortico on 6/28/21, 12:12 AM
I use this on https://vcvrack.com/manual/DSP to parse $inline$ and $$block$$ TeX into MathML with a couple lines of server-side code (simplified for readability):
html = require('markdown-it')({html: true, linkify: true, typographer: true})
.use(require('markdown-it-texmath'), {engine: 'katex', delimiters: 'dollars'})
.render(body)by chaoticsystem on 6/28/21, 3:53 AM
by helsinkiandrew on 6/28/21, 6:31 AM
I'm not a mathematician but what's the problem with client side rendering - I just about only write equations in jupyter notebooks, the syntax isn't great but it seems to work perfectly and scales to the resolution required. Math rendering is far from the most complex thing being rendered on the front end.
https://jupyter-notebook.readthedocs.io/en/stable/examples/N...
by foxes on 6/28/21, 4:09 AM
by dhosek on 6/28/21, 2:11 AM
by qubyte on 6/28/21, 8:43 AM
I'm very interested in the notion of using HTML and CSS rendering though! Many thanks to the author for pointing out this functionality.
[1]: https://github.com/qubyte/qubyte-codes/blob/main/lib/render.... [2]: https://qubyte.codes/blog/advent-of-code-2017-day-20-task-2
by lmm on 6/28/21, 1:41 AM
Every page involves the browser doing rendering work. HTML is neither fish nor fowl; it's not particularly easy to write by hand, but it's not particularly easy for the browser to parse either. I'm not convinced there are any good use cases for it, and certainly not for CSS.
If partial prerendering on the server-side meaningfully speeds up your site for end users then by all means do it. But I would follow "make it work, then make it work right, then make it work fast". Dropping in a single tag to do client-side rendering is more than enough for the 90% case.
by sharikous on 6/28/21, 11:26 AM
It would be great if we could have both natively in the browser, and maybe support for math equations as a system level feature of editors everywhere. But the vomiting-green face-woman emoji gets more money than math equations these days
by jwilber on 6/28/21, 3:56 AM
I recently used KaTeX for server-side equation rendering with node. I think people tend to just use mathjax because it’s the more popular solution for web-based equations, but after spending a week trying to render server-side with mathjax and failing, I used KaTeX and haven’t looked back.
by smoldesu on 6/28/21, 12:29 AM
by activatedgeek on 6/28/21, 5:15 AM
by amelius on 6/28/21, 11:02 AM
Uhh, this happens for anything your browser displays, so why should math be the exception?
by nichos on 6/28/21, 3:39 AM
by juped on 6/28/21, 1:26 AM
by alahijani on 6/28/21, 2:14 AM
by moonchild on 6/28/21, 12:47 AM
by kebman on 6/28/21, 4:24 AM
by lupire on 6/28/21, 12:07 AM
Sure it would be nice of browsers could render the LaTeX natively instead of using JS.
by mdoms on 6/28/21, 2:01 AM
> Images are impossible to use with copy/paste
You can select and copy text in an SVG[0]
> Images are not nearly as responsive, and are difficult to style. Line breaking, fonts, and even colors are difficult to change when using images
This is partially true, but it's not difficult to inherit your page's text colour for SVGs.
> Images are completely opaque to users in need of screen readers
Not true of SVG's with text - and in fact SVGs can have alt text which could in some cases by much more accessible to screen reader users that the raw equations[1].