Hello, current maintainer of wkhtmltopdf here. This looks like an interesting approach, as Qt/WebKit is effectively unsupported. wkhtmltopdf is further hampered by the fact that a lot of the functionality requires a patched Qt version, which hasn't been ported to Qt 5.x.<p>Switching to Blink is obvious, but which wrapper to use (CEF, Electron, etc) is hard to decide. Because they all use a multi process architecture, supporting the API around which the tools are built is not really possible. Time to work on it has also been in short supply in recent times.<p>So, good work by the authors. Wish we could get something better, but as long as browsers move at the pace they do, it's going to be tough.
wkhtmltopdf frustrates me to no end. I've even got a wrapper script to help iterate through it's various major versions and option flags in an attempt to get usable PDFs. I really hope this is a significant improvement.
If I've followed all the trails correctly, this is essentially a docker image of a wrapper around Chromium in order to print HTML to PDF.<p>wkhtmltopdf uses a WebKit browser to print HTML to PDF.
This isn't a package replacement, it's a microservice in a Docker container.<p>Replacing one package with three is nothing to be proud of. Replacing one with 13 plus wrapper code [1] is utterly ridiculous.<p>I don't know the background of this project, so there may be some important detail I'm missing, but it seems they would have done better to set up a stable wkhtmltopdf Dockerfile microservice instead, and avoid all of the wrapper code entirely. Cool as a demo of what's possible with tech today; less cool as a demo of how many hoops you can jump through to reproduce existing functionality.<p>[1] <a href="https://github.com/arachnys/athenapdf/blob/master/cli/Dockerfile" rel="nofollow">https://github.com/arachnys/athenapdf/blob/master/cli/Docker...</a>