arun1
PDF generation without Chromium dependency
ChromicPDF seems to be the popular choice for pdf generation at the moment. However, I wanted to get some community input on pdf generation libraries that DO NOT have a dependency on Chromium, puppeteer etc. I am trying to avoid the dev ops overhead of managing these additional dependencies. I would rather just draw out a PDF from scratch.
Libraries I looked into:
elixir-pdf - seems functional for the basic needs.
elixir2pdf - The underlying erlang library erlguten is giving me compilation errors so I could not test this
Does anyone have any other suggestions ?
Most Liked
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.
asianfilm
I’ve been using Typst, a Rust library for generating PDFs from markdown. Typst is also a pure functional language such that you can put display logic into functions in a template to keep such logic out of Elixir.
To use the latest version, 0.12, you’ll want to use it on the command line from Elixir. There is an Elixir library that packages the Rust for version 0.3 called ExTypst and a fork that updates it to version 0.9.
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!
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 ![]()
gushonorato
Is generating PDFs on the server strictly required? I always generate PDFs on the client side when possible. The two main reasons are:
- I don’t waste CPU cycles and memory on the server with heavy libraries.
- JavaScript has better libraries to handle PDF generation on the client side.
I’ve been using paged.js and I’m very happy with the results. It even allows me to show a preview before printing to the client.
If you really need to create PDFs on the server side, the most popular library is PdfGenerator, which uses WKHTML instead of Chrome or Puppeteer.







