How does this work? Is it WASM-based or what?
Yup, and it's all fully upstreamed in LibreOffice, see our blog (https://blog.allotropia.de/category/libreoffice/), and the upstream wiki page: https://wiki.documentfoundation.org/Development/WASM
For an even more obvious demo of that, c.f. the hidden gem https://zetaoffice.net/demos/simple-examples/rainbow_writer.... ;)
Current source version powering the demos is https://git.libreoffice.org/core/+/0d9eb8245e1a1345ed9526ad8... - we should make that more prominent, indeed.
It sounds like you might know the answer to this. Would it be straightforward to use this for sandboxed headless file conversion? You can do that already with LibreOffice, but it's a monster amount of unsafe code that's difficult to containerize securely
Indeed can be done, proof of concept shown in this talk: https://www.youtube.com/watch?v=X8LwaDjcr7M
Regarding sandboxing - everything WebAssembly is heavily sandboxed already, and requires cross-origin isolation in the browser, so we can use SharedArrayBuffers.
So that's likely no worse than running LibreOffice containerized on a server.
Oh whoa a 5 minute video for exactly this :) Apologies for making you be my Google. Yep, everything in wasm makes things much easier to work with, especially if you want to run it on a client device
I just containerized LibreOffice to do docx->pdf conversation, but now I'm wondering - what parts seem particularly gnarly to you? My naive strategy is to mount an external volume to put/collect files, then call `soffice` inside the container to process them. We generate all source docx files so I'm not worried about an injection from that angle.
It runs on ProseMirror and AG Grid.
Joke aside, the source code isn't featured on the web page, despite LibreOffice (unlike Apache OpenOffice) being copylefted. They mention self hosting, but it says to contact them. It seems it runs on WebAssembly either directly or through a VM on top of WebAssembly like https://copy.sh/v86/ . The screen seems to be simulated with a canvas. I think perhaps they didn't change the code of LibreOffice much, but have a custom setup of something like https://copy.sh/v86/ or even are running it on actual WebAssembly with a virtual screen. So they have a virtual computer that it's running on, and they consider that separate when it comes to copyleft obligations. Plus it's possible to make something open source but inconvenient, and charge to make it convenient.
From the description here[1], it sounds like they're using WASM builds of LO.
I'm not quite interested enough to spend the CPU cycles it'd take to build and see whether that is really the whole story.
[1](https://github.com/allotropia/zetajs?tab=readme-ov-file)
That's nice. AFAICT nobody has yet figured out how to run the rust compiler in WebAssembly directly, but it runs in v86. That's why I wondered if they were taking that shortcut for another complex program.
Here's their page about WASM: https://wiki.documentfoundation.org/Development/WASM
It says it uses Qt/VCL. Maybe those can talk to canvas in a fairly straightforward way, or maybe ZetaOffice chose a different backend to get a proof of concept out faster.
Side question: did GTK3's HTML renderer get anywhere? I remember a calculator application running in a browser as a demo from a long time back.
That still seems to be there, even for gtk4: https://docs.gtk.org/gtk4/broadway.html
(but it says, between the lines, mostly stale I guess)
As an aside: one of the very first demos of LibreOffice in a browser (from the Collabora people) was using the broadway backend. But they've moved on, using their own tiled rendering server backend, plus custom, javascript gui on the client.
It looks like they've developed a javascript library that interacts with a WASM build of LibreOffice: