Hacker News Reader

Comment by SigmundA | Hacker News Reader

Wkhtmltopdf is based on QtWebkit which is long deprecated. There was work to move it QtWebEngine but doesn't seem to be going anywhere: https://wkhtmltopdf.org/status.html

In the meantime Chrome added headless support and with command line or puppeteer you can do the same thing with a much newer and more secure engine.

However if you need full CSS-Paged support then PrinceXML is probably your only option and its not cheap: https://www.princexml.com

View on HN

Instead of princexml, there is an open source alternative: https://www.pagedjs.org/. I saw a demo in 2019 at the libregraphicsmeeting and it was really nice and worked well for most browser already. It probably improved since then.

Despite have a deprecated dependency, is there any issue using wkhtmltopdf? I'm running it in quite a few projects to generate letters and invoices, and not experiencing any issues.

We were generating hundred of thousands of pdfs per day with wkhtmltopdf and had a lot of reliability issues. We switched to prince, and it has proven much better on all levels; no more crashes, better layout, smaller pdfs, faster generation, etc.

Can you share any more about why you would need to generate so many PDFs from HTML?

We generate invoice PDFs from templated html using wkhtmltopdf. For B2C applications hitting millions of invoices per month is quite possible.

There are reliability problems with wkhtmltopdf, but it's possible to make it reasonably reliable with enough error detection and retrying.

Thanks, that makes sense now.

I have run into issues where it would incorrectly render svg tags.

That's interesting - have you got any more detail on that?

Yes, so there was a page of a report that showed a ‘top-view’ illustration of an item, and this svg would indicate where along the exterior of this item had damage, and where it has no damage.

So, it would become fairly inaccurate using wkhtmltopdf.

It would look like either the entire item had no issues, or it had sustained damage everywhere.

Thanks, that's good to know.

if it works for you and you control the html/css/js that is rendered, I don't think there is any problem.

There is a cheap alternative to Prince called DocRaptor which uses the prince engine but is pay per use

Basically prince adds a watermark on the first page - so you do all your revisions and then only pay for the final copy to remove the watermark (however as any editor would know, we always have many final, final final, final v3 versions ;) so paying for prince once-off at 500$ is probably the best way for anyone who needs professional pdfing.

I wrote a latex / markdown / html editor with a simple mechanism (using the browsers default print settings), I think it’s not too bad for those looking to pdf from html:

https://writer.math.dev

Issue with mine is you would have to do all style sheets in line. I would recommend serious users to either pay for Prince if they want header/footer/page number control or just use print style sheets and code the html / css themselves and use headless chrome or chrome itself to print. Many people want JavaScript in their pages, I can’t recall if headless chrome can correctly account for that. File > print is the best imo :)

> In the meantime Chrome added headless support and with command line or puppeteer you can do the same thing with a much newer and more secure engine.

Yep, this is the way to go now. Very simple API with puppeteer and everything looks the same as when viewing the page in a browser (save any @media print css).

FYI you can use the chrome dev tools to set the @media to print, great to fine tune your CSS for PDF rendering or just printing.

In my limited experience, the only thing I miss in chrome headless compared to commercial PDF to HTML tools is "smarter" page breaks support, aka avoid mostly empty pages.

I already tried to fill in a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=953313... but the spec is not very clear nor requires the most compact arrangement possible. It would probably be a worthy addition to the spec even just for the environmental impact (limiting number of pages when printing).

What I mostly miss from browsers is page numbering support. As far as I remember there is a standard but only a few commercial tools actually support it.

You can try to polyfill that with something like https://github.com/pagedjs/pagedjs

Interesting, that seems to do what I was missing.

We use wkhtmltopdf and it works fine for us. But I would like better support for newer CSS.

I like the functionality from Chrome to use it headless, but my main problem with it is that text is not selectable in the rendered PDF. It seems to be an screencapture as image or something. Anyone has this working? Selectable text is really needed for generating PDF invoices.

> text is not selectable

Here is reproducible demo that is selectable and clickable (links):

- https://majkinetor.github.io/mm-docs-template/docs.pdf

This is done using puppetear.

The same can be achieved by Save as PDF in chrome of single page containing entire site:

- https://majkinetor.github.io/mm-docs-template/print_page/

This is all part of my mm-docs framework:

- https://majkinetor.github.io/mm-docs-template

Chrome definitely does not render text or other vectors like SVG as an image.

I just tried printing the Hacker News front page to PDF in Edge which is the same engine as Chrome and the text was selectable.

Most of the time. I'm using Chrome via Puppeteer to generate PDF reports, and I've seen certain CSS rules make it render pages (or parts of them) as images. One of them was `transform` I think.

Yes transform may rasterize the content in order to transform it say as a GPU operation this is regardless of printing, this will be noticeable as blurry text and vectors on HiDpi displays.

It might be related on how you include fonts, I have seen a lot of weird behaviors unfortunately with that. Especially this response of an issue was important for my team: https://github.com/puppeteer/puppeteer/issues/422#issuecomme...

Source: working on automatic PDF reporting in my current company.

flyingsaucer [1] is also an option. [1] https://github.com/flyingsaucerproject/flyingsaucer

There’s also pdfreactor.com which we use to get full support of CSS.

paged.js embeding seems to work fine

Reply on news.ycombinator.com