Problems with math rendering on the web (2020) • Hacker News Board

Re: Problems with math rendering on the web (2020)

#21

Post by svalorzen » Mon, Jun 28, 2021, 1:17 AM UTC

kisonecat wrote: post #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 https://tex.rossprogram.org/ and at https://github.com/kisonecat/web2js 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 https://gi…

Sorry to sidetrack, but I'm also interested in implementing a Tex engine (in another language though). Any suggestions on how to learn how an engine works?

Re: Problems with math rendering on the web (2020)

#22

Post by kisonecat » Mon, Jun 28, 2021, 1:19 AM UTC

mwcampbell wrote: post #14

kisonecat wrote: post #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 https://tex.rossprogram.org/ and at https://github.com/kisonecat/web2js 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 https://gi…

> The plan is to convert ximera.osu.edu to this new backend by the fall. Have you verified that this will not be an accessibility regression for blind users?

Unfortunately, the current platform we're using isn't very accessible: the \answer{...} blanks aren't converted to speech and don't navigate correctly. The new backend parses some TeX anyway to an AST, and the idea is that we could use that to produce alt text for the math. There's certainly a lot to do.

Re: Problems with math rendering on the web (2020)

#23

Post by BeFlatXIII » Mon, Jun 28, 2021, 1:23 AM UTC

SiempreViernes wrote: post #13

Spivak wrote: post #10

Earlier quoted context omitted.

The web would be so pretty if “HTML” was actually hyperlinked TeX.

I'm not sure banner ads would be much better if aligned using TeX.

Then every web page would have dynamically-inserted underfull hboxen with a badness of 10,000

Re: Problems with math rendering on the web (2020)

#24

Post by kisonecat » Mon, Jun 28, 2021, 1:25 AM UTC

phkahler wrote: post #20

kisonecat wrote: post #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 https://tex.rossprogram.org/ and at https://github.com/kisonecat/web2js 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 https://gi…

>> I implemented a TeX engine in WebAssembly so you really can run TeX in the browser. Kinda misses the point of the blog post. The idea is to do that server side, preferably only once.

You can use the same code for server-side rendering: with dvi2html, you can run TeX on a .tex file to get .dvi and then produce a static html file. This renders not just the math but also the text using TeX's layout engine, which is often not what people want. Running it in the client means the TeX knows the width of the view.

Re: Problems with math rendering on the web (2020)

#25

Post by juped » Mon, Jun 28, 2021, 1:26 AM UTC

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.

Re: Problems with math rendering on the web (2020)

#26

Post by kisonecat » Mon, Jun 28, 2021, 1:30 AM UTC

svalorzen wrote: post #21

kisonecat wrote: post #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 https://tex.rossprogram.org/ and at https://github.com/kisonecat/web2js 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 https://gi…

Sorry to sidetrack, but I'm also interested in implementing a Tex engine (in another language though). Any suggestions on how to learn how an engine works?

TeX's source code is available in a "literate" format, so you can download tex.web, run weave tex.web, and then pdftex tex.tex. This will produce a large book with the TeX source code. A challenge is that the resulting TeX engine won't support LaTeX3, so you'll need to use "changefiles" to modify tex.web to add epsilon-TeX and other updates.

Re: Problems with math rendering on the web (2020)

#27

Post by SilverRed » Mon, Jun 28, 2021, 1:40 AM UTC

Waterluvian wrote: post #19

prezjordan wrote: post #16

I apologize if this is pedantic but you can absolutely "render" KaTeX server-side: https://github.com/jdan/thatjdanisso.cool/blob/902f1c421b02b... 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 browser…

It sounds like they want PDF. It’s rendered, not some image. But it’s also consistently laid out. I think that’s a neat idea in general. When I make little toy games for the web the part I hate the most is the boilerplate for ensuring every browser, mobile and desktop, gets a viewport of the same ratio. Would be neat to be able to say “give me a 16x9 viewport, and scale everything inside of it depending on how large…

You could create a canvas for your game and everything will be in your control.

Re: Problems with math rendering on the web (2020)

#28

Post by lmm » Mon, Jun 28, 2021, 1:41 AM UTC

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.

Re: Problems with math rendering on the web (2020)

#29

Post by SilverRed » Mon, Jun 28, 2021, 1:42 AM UTC

smoldesu wrote: post #8

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.

Unicode doesn't have many math symbols so you can't copy and paste them like text because they aren't just text.

There are textural representations though which can be copied. They just look ugly.

Re: Problems with math rendering on the web (2020)

#30

Post by thayne » Mon, Jun 28, 2021, 1:48 AM UTC

neolog wrote: post #12

The next generation is MathML. It's already implemented in Firefox, Chrome support is coming. https://www.w3.org/Math/

Firefox has supported MathML for a very long time. And I think chrome had an experimental version it for a while then removed it. I wouldn't hold my breath waiting for universal browser support.