Rendered at 13:06:59 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jerf 20 hours ago [-]
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 would be capable of overcoming LaTeX. But I could see a world where it carves out a niche and holds on to that niche for a long period of time.
PaulDavisThe1st 19 hours ago [-]
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 :(
dhosek 16 hours ago [-]
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.
PaulDavisThe1st 13 hours ago [-]
I would never advocate for DVI today.
In 1993/94 ? It was a much stronger candidate, and given that any DVI (including images) could be rendered into PDF (or whatever), its supposed technical limitations at that time were not of much significance.
stereo 12 hours ago [-]
Html back then had the same limitations.
dhosek 10 hours ago [-]
Not really. <img> was a first-class tag if not from the beginning, pretty early on and the same with color.
gjvc 17 hours ago [-]
pretty sure I remember reading about this with excitement and wonder ...
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.
jerf 19 hours ago [-]
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 may work in some sense I again have lots of questions about whether that is really "fixed".
nicoburns 19 hours ago [-]
I mean, I agree it's not fixed. I guess I'm just saying it's not the layout engine that's the blocker.
FWIW, I actually think it would be much more valuable just to fix the spec and make CSS layout fast-by-default.
exe34 17 hours ago [-]
Nowadays I imagine OCR and vllms would solve that? Tesseract is incredibly fast and accurate.
jerf 14 hours ago [-]
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.
gcr 8 hours ago [-]
This page starts flickering madly when I pinch-to-zoom. Until a11y details like this are figured out, I don’t think this should be considered for general use beyond a cool prototype.
LudwigNagasena 18 hours ago [-]
Hard to imagine anything worse than LaTeX for web layout. Imagine resizing a page and waiting for the re-compilation of the whole page.
jerf 17 hours ago [-]
That's part of the reason I'd find it so funny, yes.
The reason why I consider it a possibility is that LaTeX has two things out of the gate: The technical capability, and a small but arguably rabid user base. It's the sort of thing that can take an early lead but is quite unlikely to sustain it.
But you can't deny that LaTeX has had incredible staying power, despite the list of issues that everyone who uses it has with it.
Onavo 12 hours ago [-]
There's also PDF/PostScript as a format, but it's also made for fixed/absolute/print layouts. HTML/CSS (and I suppose related tech like XAML) were the only technologies where responsiveness was first priority.
Now if only the browser conglomerates can disrupt Pantone too...
jampekka 4 hours ago [-]
I use LaTeX daily and hate it with a passion. I kinda lost all hope when ArXiv decided to do the HTML support by hacking a LaTeX to HTML conversion.
We already have a very powerful layouting engine: the web browser. The only missing piece is printing/pagination, for which there was some CSS Paged Media progress, but that stalled.
However, why the hell are we even doing paged media? For screen viewing it's strictly worse, and very few people print papers anymore. And even for those HTML pages print passably enough.
stschaef 19 hours ago [-]
I immediately received the following error :|
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (SwiftLaTeX PDFTeX 0.3.0) (preloaded format=swiftlatexpdftex)
I can't find the format file `swiftlatexpdftex.fmt'!
Is this related to web2js[1], which has been around for a while? It compiles the pascal code of TeX to wasm.
It looks like the live demo is no longer up, but it did run latex in the browser and render the dvi output to html. The wasm for TeX is about 495kb / 88kb compressed, but the memory image for LaTeX was a bit larger.
https://www.swiftlatex.com/editor.html for the wysiwyg editor says "We are working hard to fix the editor." It has said this for many years. I think I tried it once when it was live and it was pretty cool. My guess is people observed it could corrupt documents, so it was taken down.
joshjob42 3 days ago [-]
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.
fph 16 hours ago [-]
I'm looking forward to run Lua inside Latex inside Javascript inside Firefox inside my Android ART virtual machine.
kridsdale1 17 hours ago [-]
I’m really glad the main AI chatbot apps and sites support latex rendering. I tuned my system prompts to get the bots to explain their high level reasoning in equations for me to read if they think it will convey more nuance or dimensionality than casting down to English.
jampekka 3 hours ago [-]
Please no. LaTeX and its ecosystem needs to be put out to pasture.
gs17 14 hours ago [-]
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.
andai 16 hours ago [-]
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.
christoff12 17 hours ago [-]
> 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.
exe34 17 hours ago [-]
In latex, I have to compile once so that it can find out the references it needs, then bibtex so that it extracts the actual references, compile a second time to get the references into the paper and then a third time because a ton of things shift around and now it knows all the figure/page numbers etc.
psc007 3 days ago [-]
Why is there no npm registry package?
hulitu 2 days ago [-]
> LaTeX Engines in Browsers
This is hillarious. Browsers lost the ability to print some 10 years ago.
Today, printing a web page is an exercise in masochism.
I am very curious how the output will look like.
casey2 15 hours ago [-]
Pretty funny that there is both an installation and that its not cross platform. What is the point of web assembly again?
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 would be capable of overcoming LaTeX. But I could see a world where it carves out a niche and holds on to that niche for a long period of time.
Nobody else seemed convinced :(
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.
In 1993/94 ? It was a much stronger candidate, and given that any DVI (including images) could be rendered into PDF (or whatever), its supposed technical limitations at that time were not of much significance.
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.
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 may work in some sense I again have lots of questions about whether that is really "fixed".
FWIW, I actually think it would be much more valuable just to fix the spec and make CSS layout fast-by-default.
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.
The reason why I consider it a possibility is that LaTeX has two things out of the gate: The technical capability, and a small but arguably rabid user base. It's the sort of thing that can take an early lead but is quite unlikely to sustain it.
But you can't deny that LaTeX has had incredible staying power, despite the list of issues that everyone who uses it has with it.
Now if only the browser conglomerates can disrupt Pantone too...
We already have a very powerful layouting engine: the web browser. The only missing piece is printing/pagination, for which there was some CSS Paged Media progress, but that stalled.
However, why the hell are we even doing paged media? For screen viewing it's strictly worse, and very few people print papers anymore. And even for those HTML pages print passably enough.
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (SwiftLaTeX PDFTeX 0.3.0) (preloaded format=swiftlatexpdftex) I can't find the format file `swiftlatexpdftex.fmt'!
Likewise for XeTeX
It looks like the live demo is no longer up, but it did run latex in the browser and render the dvi output to html. The wasm for TeX is about 495kb / 88kb compressed, but the memory image for LaTeX was a bit larger.
[1]: https://github.com/kisonecat/web2js
I'm not sure I understand why the second or third compile would work, but not the first.
This is hillarious. Browsers lost the ability to print some 10 years ago. Today, printing a web page is an exercise in masochism.
I am very curious how the output will look like.