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.