CSS for printed media is pretty good these days, and only getting better. MDN has a lot more on it, but this seems like it’s maybe getting off topic.
harrisi
jfpedroza
arun1
Thanks to everyone who replied, I ended up choosing Typst. The markdown is pretty powerful and easy to learn. There free online editor makes it easy to experiment with the markdown as well.
I don’t have any data to back this up but figured a rust library would be more performant than weasyprint in python
I could not get ex_typst to work, so I just called the typst compiler using System.cmd.
I have a base .typ file that has the layout and template variables. I use elixir’s EEx to fill out the data and write a .typ file to a temporary location. Finally I execute the typst compiler using the shell.
7
marceldegraaf
@arun1 not sure if you still need a solution here, but in case it helps: we’re using Gotenberg to generate PDF’s from HTML/CSS. We’re running the default Gotenberg Docker image and use the HTTP API to convert rendered Phoenix templates to PDF.
This is especially nice because we can use all the normal view helpers and Tailwind styling that we have throughout our application, and these days things like a table of contents or page numbering is pretty much solved in CSS.
Let me know if you’re interested in some example code of our setup, and the resulting PDF file!
6
acrolink
marceldegraaf
Hm, good question, I don’t know if Gotenberg allows creating multiple PDF’s at once, but we haven’t ran into any issues so far (and have this setup in production for over a year).
1
dimitarvp
marceldegraaf
Definitely!
To start of, this is how we deploy Gotenberg in Kubernetes. Any other platform should work as long as it can run Docker containers. We don’t change any configuration; this is just the vanilla Gotenberg 7 image.
Then we define some options for Gotenberg that are used in the API call when creating a PDF.
We then define a module that interacts with the Gotenberg API. It does an HTTP POST to the /forms/chromium/convert/html endpoint with our HTML page as a form/multipart request body.
Finally, define a module in your application that takes some data, renders an HTML file (from a Phoenix View), and then calls the previously defined Gotenberg API module to render it to PDF.
Hope this helps! Let me know if you have any questions 
6
dimitarvp
Super helpful, thank you. I’ll need something 99% similar very soon and will let you know if it works.
2
Lucassifoni
I’m running Chromium in production, with apps that are almost constantly generating PDFs when users are using it. Over the years I tried keeping a “hot” chromium instance always ready to convert things, but the risk of memory leaks was just too high.
Today I have either a thin puppeteer wrapper on separate infra, or this same wrapper on the same host as my app. This is because some of my clients want to run on-prem and cut off from the internet.
So I run N concurrent instances of Chromium with N consuming at most 4GB of memory simultaneously, behind N queues, so there are no more than N concurrent conversion jobs, and each chrome instance is killed after each job.
As a very popular blog post states (I think it was this one : Phantom pain: the first year running headless Chrome in production but it is different than what I recall), there’s just no guaranteed way to keep RAM usage on check long term on fixed-size infra without fully stopping chrome from time to time.
I am at very low scale but high resource usage, think of 200+ pages PDFs with a lot of high definition pictures for printing.
No incidents in a few years since I abandoned the “hot chrome instance” approach.
This Gothenberg setup looks like it could be my next step, thanks a lot for sharing this link !
4