Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LaTeX.wasm: LaTeX Engines in Browsers

swiftlatex.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: LaTeX.wasm: LaTeX Engines in Browsers

#21

Post by exe34 »

jerf wrote: post #8
nicoburns wrote: post #6

Earlier quoted context omitted.

Running layout in WASM is already practical. A good demo is https://www.nicbarker.com/clay The things you can't do are things like expose an accessibility tree (without a dummy DOM), interact with the system IME, and access system fonts.

I feel like it's fair to say that you have not "fixed the issues with browser layout" if you lose accessibility and input. System fonts I can live without, we can push our own, but those two things are a big deal. Even input you might be able to hack around but accessibility is a big deal and the "hack" at that point is nearly to both lay it out in the browser and the supposed "fixed" layout system, and while that ma…

Nowadays I imagine OCR and vllms would solve that? Tesseract is incredibly fast and accurate.

Re: LaTeX.wasm: LaTeX Engines in Browsers

#22

Post by nicoburns »

christoff12 wrote: post #19

> Due to the way Bibtex works, you may need to compile at least three times to see correct reference numbers in the PDF. I'm not sure I understand why the second or third compile would work, but not the first.

This talk contains a really good explanation of this problem (and also discussion around how it's solved in Typst) https://www.youtube.com/watch?v=yWWVhbyOWWE

Re: LaTeX.wasm: LaTeX Engines in Browsers

#23

Post by teh64 »

christoff12 wrote: post #19

> Due to the way Bibtex works, you may need to compile at least three times to see correct reference numbers in the PDF. I'm not sure I understand why the second or third compile would work, but not the first.

It is not 3 compiles of the same code after another, but e.g. latex, bibtex, latex, with each step creating part of the final output. I imagine latex like part of multi-pass compiler, so calling latex once is like running only one stage of the compiler. Latexmk (https://www.ctan.org/pkg/latexmk) solves this problem more elegantly by knowing how often each tool and in what order is required.

Re: LaTeX.wasm: LaTeX Engines in Browsers

#24

Post by fph »

joshjob42 wrote: post #3

Add LuaLaTeX and you're cookin' with gas. For real would be fantastic if we could get more or less the full LaTeX ecosystem readily and rapidly available online and in a huge variety of desktop applications.

I'm looking forward to run Lua inside Latex inside Javascript inside Firefox inside my Android ART virtual machine.

Re: LaTeX.wasm: LaTeX Engines in Browsers

#25

Post by andai »

I might be interested in running this offline too. Every time I try to do anything with LaTeX it pulls gigabytes of stuff but it's somehow still not batteries-included. I'm assuming this distribution is a bit more curated and out-of-the-box.

Re: LaTeX.wasm: LaTeX Engines in Browsers

#26

Post by fph »

christoff12 wrote: post #19

> Due to the way Bibtex works, you may need to compile at least three times to see correct reference numbers in the PDF. I'm not sure I understand why the second or third compile would work, but not the first.

There are Latex documents whose output keeps changing no matter how many times you run Latex on them: https://tex.stackexchange.com/questions/30674/document-requi...

Re: LaTeX.wasm: LaTeX Engines in Browsers

#27

Post by dhosek »

PaulDavisThe1st wrote: post #11
jerf wrote: post #5

Over the years many people have hypothesized that once WASM was really mature, it would become practical to fix the issues with web browser layout by sending down custom layout machines to users. I would find it hilarious if LaTeX turned into a leader in that space. I doubt it could hold on to that. There's a lot of things that something designed from the beginning for web-like uses could probably improve on that wou…

I added DVI support to NCSA Mosaic back in 1993-94, believing it to be a better format for "rich" documents than HTML or PDF. Nobody else seemed convinced :(

The problem with DVI is twofold:

First, font support is purely by reference which means that you need some way of connecting the fonts used in the document with the DVI file. Use of the wrong font could produce some spectacularly bad output.

Second, graphical support, other than rectangular boxes is only handled through the xxx opcode which never had any standardized meaning (although I tried). This limitation also applied to colors. Really, it was only with the final victory of PDF as the universal document format that these limitations were finally ameliorated.

Re: LaTeX.wasm: LaTeX Engines in Browsers

#29

Post by gs17 »

I really hope it can get LuaTeX support at some point, and SVG output added back in (although it hasn't been updated in two years, so it might be up to me). I have a project where this would solve a big problem if it had both of those. TikZJax might solve it better but it also doesn't support LuaTeX either and it feels like a bigger ask.

Re: LaTeX.wasm: LaTeX Engines in Browsers

#30

Post by jerf »

exe34 wrote: post #21
jerf wrote: post #8

Earlier quoted context omitted.

I feel like it's fair to say that you have not "fixed the issues with browser layout" if you lose accessibility and input. System fonts I can live without, we can push our own, but those two things are a big deal. Even input you might be able to hack around but accessibility is a big deal and the "hack" at that point is nearly to both lay it out in the browser and the supposed "fixed" layout system, and while that ma…

Nowadays I imagine OCR and vllms would solve that? Tesseract is incredibly fast and accurate.

Accessibility is not just about getting text out. It's about the navigation flow, integration into various OS features, Aria attributes in HTML and what they do. Plus you may not count this as "accessibility" but things like integrating fully with multi-lingual text entry methods.

It's solvable, except for what isn't solvable because the browser doesn't expose it, which can be solved by fixing that too. But it's a lot more work than meets the eye. And building the layout engine is hard enough in the first place. Give me a week and an AI budget and I'll produce you some sort of layout engine that works when fed exactly the sorts of inputs I anticipated, but to build something that survives contact with the real world is going to be well beyond something you just prompt your way around today.

Post reply on HN