I've used wkhtmltopdf heavily for years and it is a disaster today. Font rendering is inconsistent across systems, its CSS/HTML support is frozen in time many years ago.
The author's suggested alternative doesn't use a real browser rendering engine, it uses its own CSS/HTML parsing and rendering implementations (!!!). I don't trust it to keep up with standards and don't want content authors to have to deal with yet another dialect of HTML/CSS with its own pile of quirks. We already know Chrome's capabilities and quirks and I'm quite happy with Chrome's print menu and the output of my backend PDF generator being the same thing.
> The CSS layout engine is written in Python, designed for pagination, and meant to be easy to hack on.
Raise your hand if you want to hack on a CSS layout engine in Python while generating your PDFs. I'll wait
Re:Wkhtmltopdf Considered Harmful
by TobalJackson on Thursday July 19, 2018 @01:45PM
(#17568719)
Came here to mention puppeteer since I didn't see it in the author's suggestions. I developed a huge script at my last job which processed PST files into PDFs, and it relied heavily on wkhtmltopdf.
After discovering the issues surrounding font embedding and lack of interoperability with windows/adobe acrobat (when redacting) I was tearing my head out trying to figure out how to get it to work. In the end, I chalked it up to being a limitation of how the program handled fonts, and looked for an alternative.
After discovering puppeteer and dropping it in (replacing wkhtmltopdf), basically all the problems I was having with fonts disappearing were solved. Did not look back.
Re:Wkhtmltopdf Considered Harmful
by unilynx on Thursday July 19, 2018 @02:02PM
(#17568852)
And to add to this: for the other side of the equation (watermarking/backgrounds, joining, splitting, pdf to img) use Apache's PDFBox
I've been through so many combinations of fop/flyingsaucer/wkhtmltopdf/phantom and pdftk/mcpdf/qpdf over the last decade.... but it seems we're finally about to solve this problem...
Re:Wkhtmltopdf Considered Harmful
by KiwiCoder on Thursday July 19, 2018 @11:58AM
(#17567514)
I will join the chorus - wkhtmltopdf has been working fine in production for many months, reliably producing thousands of 10+ page PDFs with cover pages, headers, footers, page numbering, and images. Sure, it takes bit of fiddling to get it working as you like the first time - as most non trivial things do - but I've no regrets and would recommend it.
Re:Wkhtmltopdf Considered Harmful
by matz1 on Thursday July 19, 2018 @12:43PM
(#17568061)
This wrong usage of 'Considered Harmful' is Considered Harmful. I've been using wkhtmltopdf to enormous amount of pdf and it has been fine. I will try to replace it with chrome headless though for future project just because its newer.
Re:Wkhtmltopdf Considered Harmful
by brassattax on Thursday July 19, 2018 @11:48AM
(#17567401)
I have been using Wkhtmltopdf to build pdfs in my application for quite a while. It has never caused any harm. Actually it has always "just worked" and is a good fit for my app.
Re:Wkhtmltopdf Considered Harmful
by kkaske on Thursday July 19, 2018 @12:00PM
(#17567537)
I was going to say the same thing. I actually had to go back and check to see if that is what I was using. I set it up so long ago and have never had to mess with it that I forgot. Works great for me!
Re:Wkhtmltopdf Considered Harmful
by astrodust on Thursday July 19, 2018 @12:37PM
(#17567990)
The biggest problem is it's HTML based and WebKit based. Things that are trivial to do in a native PDF drawing library are a total pain because of the CSS factor.
Re:Wkhtmltopdf Considered Harmful
by jessewmc on Thursday July 19, 2018 @12:26PM
(#17567843)
The last line of the article is "We'll be keeping an eye on weasyprint." I'm pretty sure that means they don't think it's ready yet, and aren't using it yet. It looks promising but they don't directly test it against any of their complaints!
I, like many people in this thread, have used wkhtmltopdf for years and it works pretty well.
Re:Wkhtmltopdf Considered Harmful
by icebraining on Thursday July 19, 2018 @12:03PM
(#17567576)
Curious they didn't mention our main problem: every single release changed something in the output. Upgrading fixed a bug and brought another; every minor version required hours of tests to verify multiple copies (single page, multiple page, long pages, etc) of every report. We ended up just applying the specific patches and building it ourselves.
The developers are hard-working and helpful (@ashkulz even commented on a commit on my personal fork!), I just think the job is too big for the resources they have. Too many edge cases.
Re:Wkhtmltopdf Considered Harmful
by nathan_f77 on Thursday July 19, 2018 @12:03PM
(#17567581)
I used wkhtmltopdf to build the HTML/CSS templates [1] in FormAPI [2]. I agree with all the points, but they haven't really been dealbreakers. It's been working fine, at least for simple things like invoices. weasyprint does sound a lot better though, so I'll probably switch to that.
Also I didn't realize that DocRaptor has an integration with Heroku. I should really look into that.
Re:Wkhtmltopdf Considered Harmful
by danenania on Thursday July 19, 2018 @12:26PM
(#17567842)
Funny, I just implemented wkhtmltopdf yesterday (via ruby's PDFKit) for invoice generation. None of the issues listed are a big deal for our very simple use case, but I did have to rebuild docker images a bunch of times in order to figure out the right dependencies on debian. I couldn't find a canonical list of these anywhere. The binaries installed through apt-get are also outdated and didn't work for me, so I ended up using the wkhtmltopdf-binary gem.
These are the os dependencies I ended up needing: libxrender1, libxext6, and libfontconfig.
So yeah - the library is fine, but installation ux/docs could use work.
Re:Wkhtmltopdf Considered Harmful
by gandhium on Thursday July 19, 2018 @12:05PM
(#17567606)
Looks like they just choose a wrong library. Wkhtmltopdf is intended (as name implied) to convert HTML to PDFs, like 'we rendered this nice page in browser using D3 and fancy set of CSSs, now we need to export it to PDF'.
And their grievance is about abilities to generate PDFs from a template with a predefined presets. Clearly, other libraries will suit that task better.
Re:Wkhtmltopdf Considered Harmful
by inferiorhuman on Thursday July 19, 2018 @12:45PM
(#17568078)
If headers and footers are a significant issue something like XSL-FO (with Apache fop) may be a better idea. But then you're trading one monster for another.
Re:Wkhtmltopdf Considered Harmful
by type0 on Thursday July 19, 2018 @02:18PM
(#17568972)
Prawn is nice, too bad it's incomplete though, I wish Weasyprint was there but you just can't guess when and how it will fail on you. At least Puppeteer is predictable that way, it's good for invoices, short reports and other small stuff, it's not really suitable for anything bigger.
Re:Wkhtmltopdf Considered Harmful
by thsowers on Thursday July 19, 2018 @12:12PM
(#17567694)
I've used wkhtmltopdf for many years, and although it certainly has it's issues, it does work once you get it to a stable point. Is it as easy to get there as it should be? No
Recently, I've been investigating writing new projects in react-pdf
Re:Wkhtmltopdf Considered Harmful
by rahimnathwani on Thursday July 19, 2018 @01:05PM
(#17568348)
I tried using Weasyprint ~9 months ago, and really wanted to like it. But lack of features meant it couldn't render my (not that complex) page properly. So I switched back to wkhtmltopdf.
Re:Wkhtmltopdf Considered Harmful
by coldtea on Thursday July 19, 2018 @01:41PM
(#17568694)
All of the reasons mentioned were BS when wkhtmltopdf was in active development, as, even with all that, wkhtmltopdf (and phantom.js later) was the only game in town.
Re:Wkhtmltopdf Considered Harmful
by smacktoward on Thursday July 19, 2018 @12:05PM
(#17567604)
> PDF is an ancient format, as old as the Web. It was introduced in 1993
Just because something is old doesn't mean it's bad. "Old" can also mean "well-understood" and "widely implemented," both of which are true of PDF. I can make a PDF and be reasonably confident that it can be read on any platform under the sun, and that someone needing to transform it will have plenty of tools available to do so. Neither of these things are true of XPS, or really any other competing format save HTML, which isn't really comparable as it aims to solve different problems than PDF does.
There are definitely things to not like about PDF, but its age isn't one of them.
Re:Wkhtmltopdf Considered Harmful
by masukomi on Thursday July 19, 2018 @02:19PM
(#17568987)
i was recently looking for a good html to pdf solution and found wkhtmltopdf and weasyprint results to be... poor at best. turns out, you can do it on the command line via a call to Google Chrome and the results are great. Details here: https://weblog.masukomi.org/2018/05/25/html-to-pdf-on-the-co...
Re:Wkhtmltopdf Considered Harmful
by baccredited on Thursday July 19, 2018 @12:05PM
(#17567611)
Mainly the single file output. And PDFs fit nicely into our (ancient) document management tools. Also pretty confident they will look the same despite browser changes down the road.
I built a basic CLI wrapper to make it easy to drop it in in place of wkhtmltopdf: https://www.npmjs.com/package/puppeteer-cli
I've used wkhtmltopdf heavily for years and it is a disaster today. Font rendering is inconsistent across systems, its CSS/HTML support is frozen in time many years ago.
The author's suggested alternative doesn't use a real browser rendering engine, it uses its own CSS/HTML parsing and rendering implementations (!!!). I don't trust it to keep up with standards and don't want content authors to have to deal with yet another dialect of HTML/CSS with its own pile of quirks. We already know Chrome's capabilities and quirks and I'm quite happy with Chrome's print menu and the output of my backend PDF generator being the same thing.
> The CSS layout engine is written in Python, designed for pagination, and meant to be easy to hack on.
Raise your hand if you want to hack on a CSS layout engine in Python while generating your PDFs. I'll wait
After discovering the issues surrounding font embedding and lack of interoperability with windows/adobe acrobat (when redacting) I was tearing my head out trying to figure out how to get it to work. In the end, I chalked it up to being a limitation of how the program handled fonts, and looked for an alternative.
After discovering puppeteer and dropping it in (replacing wkhtmltopdf), basically all the problems I was having with fonts disappearing were solved. Did not look back.
I've been through so many combinations of fop/flyingsaucer/wkhtmltopdf/phantom and pdftk/mcpdf/qpdf over the last decade.... but it seems we're finally about to solve this problem...
The thing makes ImageMagick look well architected and streamlined.
Wkhtmltopdf is far and away the best solution (at least in Ruby land) even if it is often painful to work with.
> TL;DR: replace it with weasyprint.
I, like many people in this thread, have used wkhtmltopdf for years and it works pretty well.
The developers are hard-working and helpful (@ashkulz even commented on a commit on my personal fork!), I just think the job is too big for the resources they have. Too many edge cases.
Also I didn't realize that DocRaptor has an integration with Heroku. I should really look into that.
[1] https://formapi.io/templates/tpl_mFAsZEmhCtG9FX5N/edit
[2] https://formapi.io
[1] https://github.com/GoogleChrome/puppeteer
These are the os dependencies I ended up needing: libxrender1, libxext6, and libfontconfig.
So yeah - the library is fine, but installation ux/docs could use work.
No mention in this of headless chrome - setup as a lambda service is also pretty nice
And their grievance is about abilities to generate PDFs from a template with a predefined presets. Clearly, other libraries will suit that task better.
https://developers.google.com/web/updates/2017/04/headless-c...
Recently, I've been investigating writing new projects in react-pdf
Now we have Chrome headless etc as well.
Just because something is old doesn't mean it's bad. "Old" can also mean "well-understood" and "widely implemented," both of which are true of PDF. I can make a PDF and be reasonably confident that it can be read on any platform under the sun, and that someone needing to transform it will have plenty of tools available to do so. Neither of these things are true of XPS, or really any other competing format save HTML, which isn't really comparable as it aims to solve different problems than PDF does.
There are definitely things to not like about PDF, but its age isn't one of them.
It's not a dig against the format.
Considered harmful is kind of a tired cliche.
It ended up being "8 reasons why I dislike Wkhtmltopdf"