Interesting, I'm looking for a solution to render PDFs at the moment, it looks like that one actually does not use chromium, unlike most tools that I've seen that render HTML to PDFs.
What's the advantage? Is it more lightweight / faster / reliable?
We actually ran off of WeasyPrint at first but switched to Chromium due to emojis not rendering properly, poor flexbox support, no custom fonts, and other differences between the HTML you'd see in a browser vs. the generated PDF.
WeasyPrint implements its own rendering engine and might support some specific @page properties that Chromium does not but given the complexity of CSS and web browsers, you're generally better off sticking with Chromium due to its history.
Also – an added benefit is that we can use JS libraries like FontAwesome, Bootstrap, KaTeX, etc. which is where other HTML to PDF libraries fall flat.
Flexbox support has been [included][1] since 2018, although my use case was the prototypical one - a single row w/ 3 columns - so YMMV with how it handles more complex layouts.
In addition, so far I know, the @page "locations" (e.g, @top-center, etc.) are not well supported yet in all browsers which means the flexbox fallback is probably as close as we're going to get.
wkhtmltopdf[1] uses the QT WebKit renderer. I used it as part of my job hut work-flow with pandoc to get pdf resumes from markdown. It got me a job, so there's that.
I used the same [0], however wkhtmltopdf stopped working correctly at some point, so I am stuck printing the pdf manually with chrome at the moment. Probably an update that broke some stuff.
agree with the other comment - I made my resume in HTML / CSS, and the most reliable way to generate a PDF is just Chrome's print to PDF. I tried weasyprint and wkhtmltopdf and they either dropped elements or changed the layout.
