Please find a way to run this without building Chromium

[Emanuele Sabetta]

I work on an environment where I cannot compile binaries and run them.
Pure scripts, like bash, python, c# script, javascript/typescript or WASM, are fine.
Can you make this amazing tool available without having to compile chromium and run it?
This tool deserves to be more portable.

[OpenFoam-User]

What's wrong with using docker instead?

[Emanuele Sabetta]

What's wrong with using docker instead?

Docker costs money. Unless you are going to host it?

[Fathy Boundjadj]

Can you make this amazing tool available without having to compile chromium and run it?

Something we can do though is ship binaries for macOS and Linux which should allow you to run without Docker on those platforms.

Docker costs money. Unless you are going to host it?

I'm not super familiar with Docker licensing terms, but it should be free for personal use. The image is exported as a standard OCI image (open-source format for container image), so you can use it with free software like containerd or podman: docker uses containerd internally and podman provides a very similar interface to docker.

If you're worried about rate-limit on hub.docker.com, you can export the image into a .tar.gz file to import it offline.

[Emanuele Sabetta]

@fathyb wrote:

I'm not super familiar with Docker licensing terms, but it should be free for personal use.
If you're worried about rate-limit on hub.docker.com, you can export the image into a .tar.gz file to import it offline.

Of course in my work environment Docker is also not allowed. So the only option is using an online hosting service like AWS, Azure, etc. But that requires money.
Some hosting services allows some free tier hosting of docker images but with huge limitations on data rate, memory, cpu and space.
For example Heroku is widely used on Github, you can see many projects with the Heroku ‘deploy’ button:
https://devcenter.heroku.com/articles/heroku-button
But even if it is free, can you make it a heroku compatible web app docker image and add an heroku button to html2svg?
Here is an example project: https://github.com/mohsinxmushtaq/strapi-heroku-app

Some popular free-tier alternatives to Heroku:

https://render.com/docs/deploy-to-render
https://www.koyeb.com/docs/deploy-to-koyeb-button
https://railway.app/button
https://docs.netlify.com/site-deploys/create-deploys/#deploy-to-netlify-button
https://developers.scalingo.com/one-click/index
https://docs.cyclic.sh/how-to/create-deploy-to-cyclic-button

[Garnet]

Hey @Emasoft for most Docker containers it's possible to extract the image contents, mount /proc+/dev (sometimes), chroot, and run the entrypoint. I've tested that process on a CentOS Linux server that does not have any docker/podman installed and html2svg is working:

wget https://raw.githubusercontent.com/jjlin/docker-image-extract/main/docker-image-extract
chmod +x docker-image-extract
./docker-image-extract fathyb/html2svg
# Content saved to "./output/"
mount --types proc /proc ./output/proc
mount --bind /dev ./output/dev
# I didn't mount /sys; I also didn't use --rbind; it worked fine; ymmv
chroot output
$ /app/scripts/docker-entrypoint.sh --help
$ /app/scripts/docker-entrypoint.sh http://google.ca > ~/result.svg
$ ^D
# Note the "~" is different in and out of the chroot
cp output/root/result.svg ~/
open ~/result.svg

---

This is a 1.9GB folder (mostly libLLVM and /usr/gcc taking up space, but also xvfb x server). You might be able to more delicately integrate html2svg with your host system for a much smaller size - the /app folder for html2svg's 1st party code is only 220MB - but this is a bit weird to get the dependencies right. You'll need Xvfb to be runnable. Extract just the /app to the server, change /app in the JS code (see /app/build/ folder) to not use an absolute path, and then run with Node 18. It's nice that the code isn't minified! Should be pretty hackable. Try:

export DISPLAY=:99

Xvfb $DISPLAY -screen 0 1920x1080x24 &
node /app/build/html2svg.cli.js http://example.org

Also strace is helpful to debugging. In particular, Electron will fail with "Trace/breakpoint trap" error if it can't access /dev/shm which is why it's necessary to mount /dev.

Note I haven't taken this route since the chroot is working just fine on my headless server and I don't have X installed (and don't want to muck with that installation). Good luck!

[Emanuele Sabetta]

@heyheyhello Thanks a lot! I shall try! 🙂

[Fathy Boundjadj]

I wanted to share some progress on that: I rewrote html2svg in Rust and switched to using a custom headless implementation instead of Electron + xvfb. Combined with a new terminal back-end, this resulted in a new terminal-based browser named Carbonyl weighting ~50 MB compiled and not requiring any window manager.

html2svg is going to move to being a Node.js wrapper around Carbonyl + format optimizers such as SVGO to make maintenance easier. This removes the need for Docker and allows for a public npm package, so the installation will be a simple npm install @fathyb/html2svg. Still have a few things to iron out, but it should be available in the next few weeks!