Problems with math rendering on the web (2020)

135 点作者 uuuuuuuuuuuu将近 4 年前

26 条评论

kisonecat将近 4 年前

I implemented a TeX engine in WebAssembly so you really can run TeX in the browser. You can see a demo of this at <a href="https://tex.rossprogram.org/" rel="nofollow">https://tex.rossprogram.org/</a> and at <a href="https://github.com/kisonecat/web2js" rel="nofollow">https://github.com/kisonecat/web2js</a> you can find a Pascal compiler that targets WebAssembly which can compile Knuth's TeX. Interesting primitives like \directjs are also implemented, so you can execute javascript from inside TeX. The rendering is handled with <a href="https://github.com/kisonecat/dvi2html" rel="nofollow">https://github.com/kisonecat/dvi2html</a> for which I finally fixed some font problems.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.

评论 #27656997 未加载

评论 #27656745 未加载

评论 #27656918 未加载

评论 #27657097 未加载

评论 #27656865 未加载

joppy将近 4 年前

The "server-side rendering" aspect of KaTeX is (and always has been, as far as I'm aware) front-and-centre on their landing page [1]. It allows you to input LaTeX and output HTML ready for inclusion server-side - the only thing this HTML needs to support it is the KaTeX CSS. This is very easy to do if your web server or static site generator is running on Node, and only a bit more difficult if it's running on something else (and therefore needs to shell out to Node). So if the author wants a good solution to server-side rendering, just look a little more at KaTeX.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]: <a href="https://katex.org/" rel="nofollow">https://katex.org/</a>

评论 #27658165 未加载

评论 #27660879 未加载

daymi将近 4 年前

This article is kinda weird--it mentions MathML in passing and then spends a large amount of time on MathJax etc.The correct fix is to have MathML natively on all browsers (no JS)--and Igalia is working on that: <a href="https://mathml.igalia.com/faq/" rel="nofollow">https://mathml.igalia.com/faq/</a>

评论 #27657487 未加载

评论 #27658077 未加载

prezjordan将近 4 年前

I apologize if this is pedantic but you can absolutely "render" KaTeX server-side: <a href="https://github.com/jdan/thatjdanisso.cool/blob/902f1c421b02b9de419f85aeecee94ef1fe781b1/load-article.js#L26-L30" rel="nofollow">https://github.com/jdan/thatjdanisso.cool/blob/902f1c421b02b...</a>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.

评论 #27656992 未加载

crazygringo将近 4 年前

> ...they use client-side rendering for static content. In my opinion, this is absurd.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.

评论 #27658227 未加载

评论 #27658024 未加载

TheRealPomax将近 4 年前

The state of maths on the web, as someone who uses a lot of maths on their website[1] is to recognise that loading times on the web shouldn't exist, and you should just turn your formulae into images that you load using `loading="lazy"`. And of course, to make sure they fit any resolution: generate SVG images.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] <a href="https://pomax.github.io/bezierinfo" rel="nofollow">https://pomax.github.io/bezierinfo</a>[2] <a href="https://github.com/Pomax/BezierInfo-2/blob/master/src/build/markdown/processors/latex/latex-to-svg.js" rel="nofollow">https://github.com/Pomax/BezierInfo-2/blob/master/src/build/...</a>[3] <a href="https://github.com/Pomax/BezierInfo-2/blob/master/.github/workflows/post-merge.yml" rel="nofollow">https://github.com/Pomax/BezierInfo-2/blob/master/.github/wo...</a>

评论 #27659233 未加载

评论 #27659654 未加载

评论 #27658944 未加载

评论 #27659614 未加载

评论 #27671086 未加载

neolog将近 4 年前

The next generation is MathML. It's already implemented in Firefox, Chrome support is coming.<a href="https://www.w3.org/Math/" rel="nofollow">https://www.w3.org/Math/</a>

评论 #27657289 未加载

vortico将近 4 年前

KaTeX supports server-side Node rendering pretty easily. <a href="https://katex.org/docs/node.html" rel="nofollow">https://katex.org/docs/node.html</a> Maybe MathJax does too, but I haven't checked.I use this on <a href="https://vcvrack.com/manual/DSP" rel="nofollow">https://vcvrack.com/manual/DSP</a> to parse $inline$ and $$block$$ TeX into MathML with a couple lines of server-side code (simplified for readability):<pre><code> html = require('markdown-it')({html: true, linkify: true, typographer: true}) .use(require('markdown-it-texmath'), {engine: 'katex', delimiters: 'dollars'}) .render(body)</code></pre>

chaoticsystem将近 4 年前

I have use MathML with Latex2mathml python library <a href="https://github.com/roniemartinez/latex2mathml" rel="nofollow">https://github.com/roniemartinez/latex2mathml</a>. And is great, the fact that you can render math without a single line of java script. But at the end, only Firefox fully supports MathML, without Chrome support is kind of useless.

helsinkiandrew将近 4 年前

> they use client-side rendering for static content. In my opinion, this is absurdI'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.<a href="https://jupyter-notebook.readthedocs.io/en/stable/examples/Notebook/Typesetting%20Equations.html" rel="nofollow">https://jupyter-notebook.readthedocs.io/en/stable/examples/N...</a>

评论 #27662692 未加载

foxes将近 4 年前

Why do we except a server to render maths for us? The client renders HTML/SVG. Maths is text, we should take the same approach. There just needs to be a compact markdown for maths notation. MathML is an awful mess.

dhosek将近 4 年前

I've had a similar argument for years. Before there was CSS to do rounded corners on boxes, it was typical to do a hack with JS building up the rounded corners pixel by pixel. On the project I was working on, since all the rounded boxes were generated by the same component, I eliminated the client-side JS for a statically-generated set of output that did the same thing. It rendered noticeably faster. And I was overridden by the other team members who apparently felt it was better to manage this through having every single client render the rounded corners on their underpowered computers (this was for a company intranet and from the discussions about system requirements, most of the machines were running old versions of Windows on old PCs) instead of doing it once and for all on the server.

qubyte将近 4 年前

I use server rendered SVG with mathjax as part of my static site generator. To try to make it as accessible as possible I add a title element with an ID to each SVG and use an aria-labelledby attribute to connect the two [1] (a sample for the interested, scroll about half way down [2]). The title content is the unrendered LaTeX source.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]: <a href="https://github.com/qubyte/qubyte-codes/blob/main/lib/render.js#L20-L42" rel="nofollow">https://github.com/qubyte/qubyte-codes/blob/main/lib/render....</a> [2]: <a href="https://qubyte.codes/blog/advent-of-code-2017-day-20-task-2" rel="nofollow">https://qubyte.codes/blog/advent-of-code-2017-day-20-task-2</a>

lmm将近 4 年前

I still render Markdown on the client. My blog is probably "slow" by 2000s standards, but it's far faster and more lightweight than a typical news website in 2020.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.

评论 #27658333 未加载

sharikous将近 4 年前

We already have two standardized ways to write math equations: MathML and TeX-like notation. The former is the formal standard, the second is what is overwhelmingly used.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

jwilber将近 4 年前

This wasn’t very in-depth at all if I’m being honest.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.

smoldesu将近 4 年前

Ha! I used to get pretty pissed-off when I was doing my online math homework, only to find that you couldn't copy/paste the equations into Google. I always thought it was a prevention mechanism, but I guess it was a matter of the technology not being ready yet.

评论 #27657253 未加载

评论 #27657980 未加载

activatedgeek将近 4 年前

This article is odd. I use pre-rendered KaTeX with remark [1], plus their stylesheet on the client side. All of the article seems more specific to MathJax than the title seems to convey.[1]: <a href="https://remark.js.org" rel="nofollow">https://remark.js.org</a>

amelius将近 4 年前

> they use client-side rendering for static content. In my opinion, this is absurd.Uhh, this happens for anything your browser displays, so why should math be the exception?

nichos将近 4 年前

I thought adding LaTeX (or similar) to the Gemini protocol was a huge missed opportunity. It could be the standard for research and universities.

评论 #27660160 未加载

juped将近 4 年前

What I actually want isn't to run some more d----d javascript "server side", but to process latex to html in e.g. a hugo build.

alahijani将近 4 年前

A translating reverse proxy could do the server-side rendering, and also cache the TeX snippets for faster response time.

moonchild将近 4 年前

See: mathml.

kebman将近 4 年前

Ah, math rendering. The last bastion of HTML.

lupire将近 4 年前

Eh. Every client already renders all the HTML into visual format. I don't see what's wrong with rendering the LaTeX too.Sure it would be nice of browsers could render the LaTeX natively instead of using JS.

评论 #27656754 未加载

mdoms将近 4 年前

The author treats SVG as equivalent to PNG and complains that> Images are impossible to use with copy/pasteYou 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 imagesThis 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 readersNot 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].[0] <a href="https://www.w3.org/TR/SVG/text.html" rel="nofollow">https://www.w3.org/TR/SVG/text.html</a>[1] <a href="https://css-tricks.com/accessible-svgs/" rel="nofollow">https://css-tricks.com/accessible-svgs/</a>