Hello @maltoe. Just came across your lib and put it to work in the current project. Over the last number of years I always used https://wkhtmltopdf.org/ with very good results (Yes, I read your text saying that you might not be able to concur) so I’d normally do the same this time. Especially that there is a well established Elixir wrapper for it. But this project is a little different than previous ones. There I typically had a “web view” and “print view” separated, both with different markup. This way I was able to fine-tune the markup fed to wkhtmltopdf independently from the browser window view of the same document. This worked excellent for me. In this project though I want users to be able to press the key combination they usually press in order to print the webpage, and have the printed (or browser-pdf-exported) document looking the same as it looks on a generated PDF. This is where things start to be “less than optimal” for wkhtmltopdf if I don’t want to scale back the browser view to the HTML and CSS, which wkhtmltopdf can chew. Especially Flexbox stuff is problematic for it. This is an understandable result if the underlying WebKit hasn’t been updated for a long while. Therefore, all in all looks like a perfect moment to give a stab at something else then.
Theoretically I could still use the PdfGenerator as it currently supports generating PDFs through Chrome too but the first point on your features list is such a teaser that I couldn’t resist 
I mean the part about “Node.js” of course…
So, I’ve got the first document saved in PDF format relatively quickly, proving that your thing actually works Moreover the output looks the same in the PDF generated from ChromicPDF and the one “printed to PDF” from browser window. This is exactly what was needed and while it was to be expected it is still nice to see this be in fact the case. So far this is all great (and here comes the “but”) but…
- whether pooled or “on_demand” it is slow. About 2 to 2.5 times slower than processing the same HTML with `wkhtmltopdf. This means that while I was usually able to deliver generated PDFs synchronously in less than a second even under some load, over two seconds with no load begs for async processing (and a job queue!)
- the output is “bloated”. This type of documents comes out of
wkhtmltopdfas about 40KiB. Maybe 50 KiB on occasions. Chrome puts out not less than five times as many bytes…
Please don’t get me wrong - this is not a complaint about things I know you have little to no influence on. It is more for others about what to expect if someone finds himself in a position similar to mine: I really don’t feel like rewriting the whole, fine-tuned markup for wkhtmpltopdf and manually (well, “eyeually”) testing – how else? – that the two generation paths deliver visually the same result. All in all I haven’t yet 100% decided but I am very much tending towards ChromicPDF. Vision of writing two sets of markup for each type of document, and especially maintaining them later in visual sync is a highly un-promising one
