While it is an amazing technical feat, there are, expectedly, a bunch of quirks to be ironed out. The font rendering, for example, is very bad. Very excited to see how this goes in the future!
That's excellent! You guys should interact with Nextcloud or someone should try their hand at a Nextcloud App [1]. Nextcloud's solution to Google Docs & friends is via the integration of OnlyOffice[2], which requires a DocumentServer [3] to function in the context of Nextcloud. Even without the collaboration aspect, having LibreOffice work off WASM, without any extra infrastructure requirement would be an excellent edition to that ecosystem I think.
Zeta.js is such an impressive JavaScript library. I'm blown away. The examples where you can load a document in less than ten lines, amazing. Then, change colors of all cells in less than ten lines, amazing.
I'm also blown away that there is a gulp file in the repository. That's a blast from the past.
I'm still working with stuff using grunt (most certainly not my choice). gulp is not that bad as a generic task runner, though the last thing I'd use it for these days is to build JS artifacts.
I can remember testing libre office in the browser many years ago, seems like that project was frozen in 2020 as others external projects emerged. The wiki has a guide for docker:
the link you refer to talks about collabora and allotropia. the first is what powers Nextcloud Office/Collabora Office online and mobile apps (using coolwsd). the latter is allotropia, who is behind Zeta that is mentioned here. both have a slightly different approach to how this works.
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
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
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.
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.
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.
(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.
While it is an amazing technical feat, there are, expectedly, a bunch of quirks to be ironed out. The font rendering, for example, is very bad. Very excited to see how this goes in the future!
That's excellent! You guys should interact with Nextcloud or someone should try their hand at a Nextcloud App [1]. Nextcloud's solution to Google Docs & friends is via the integration of OnlyOffice[2], which requires a DocumentServer [3] to function in the context of Nextcloud. Even without the collaboration aspect, having LibreOffice work off WASM, without any extra infrastructure requirement would be an excellent edition to that ecosystem I think.
[1] https://apps.nextcloud.com/
[2] https://www.onlyoffice.com/
[3] https://github.com/ONLYOFFICE/DocumentServer
Zeta.js is such an impressive JavaScript library. I'm blown away. The examples where you can load a document in less than ten lines, amazing. Then, change colors of all cells in less than ten lines, amazing.
I'm also blown away that there is a gulp file in the repository. That's a blast from the past.
I'm still working with stuff using grunt (most certainly not my choice). gulp is not that bad as a generic task runner, though the last thing I'd use it for these days is to build JS artifacts.
I can remember testing libre office in the browser many years ago, seems like that project was frozen in 2020 as others external projects emerged. The wiki has a guide for docker:
https://wiki.documentfoundation.org/Development/LibreOffice_...
the link you refer to talks about collabora and allotropia. the first is what powers Nextcloud Office/Collabora Office online and mobile apps (using coolwsd). the latter is allotropia, who is behind Zeta that is mentioned here. both have a slightly different approach to how this works.
how is this different from http://www.collaboraoffice.com/ ?
Collabora works on mobile devices and integrates with Nextcloud
note: they use WASM, so the load is on the client. Collabora relies on a server part, though easy to host.
Love the Deep Space 9 Easter egg!
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
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:
https://github.com/allotropia/zetajs?tab=readme-ov-file