Long term plans given the deprecation of wkhtmltopdf?

[nclark]

Issue description

I apologize if this is the wrong forum to ask in. I have searched the issues and docs, I didn't find any sort of position on the future of this project with respect to the wkhtmltopdf deprecation. I did come across #1047 but that doesn't address the deprecation, and #1045 hints that we're unlikely to see a second engine supported.

I've used wicked_pdf for a long time and it's been great, and it's working great for me now. I'm just curious if there are long term plans like switching engines, sun-setting this project, etc., and I'm curious to hear from other users how they are thinking about future-proofing their own projects.

[unixmonkey]

Pretty much all of WickedPDF is tailor made to wrap around wkhtmltopdf, warts and all. Even though it is now deprecated, there are so many projects out there using it, I personally don't want to abandon them, or prevent them from being able to upgrade to the newest Ruby, Rails, or asset pipeline-like framework for Rails. No plans on sunsetting WickedPDF, or even stopping development, but I have started to try and steer people to alternatives, especially for those just starting out.

I'm not too keen on bringing in support for alternative PDF generation tools into this project, mostly because they are going to be so different. I'd rather start a whole new project around that new tool than extend this one to work with some kind of shared architecture. One that doesn't have to deal with years (decades) of baggage.

Is there an alternative tool for generating PDFs similarly that you think needs a better wrapper?

[nclark]

Thanks for your response @unixmonkey. It makes a ton of sense and your consideration for users is encouraging. I suppose I'm just not sure what the potential impact is on me as a user from the upstream project being archived. Maybe a new version of the spec is released, and I'm just frozen in time, and it's a simple as that. Which can make sense for a while, I'm just trying to understand my options long term.

As far as other tools, I'm not really familiar with anything besides prawn. I would say 90% of my experience with PDFs is from using wkhtmltopdf through this gem.

[unixmonkey]

Yeah, I think I understand. If you've been using wkhtmltopdf for a long time, and your app currently works, you have the following choices:

1. Do nothing. The latest wkhtmltopdf binary won't disappear from the internet, it just won't get updates. It may work for a very long time; maybe longer than your app.
2. Adopt some new tool and start replacing your PDF generation to use that new tool, and phase out wkhtmltopdf until it is no longer needed.

Choosing option 1 is easy, and choosing option 2 stinks. Why rebuild if it works? I risk breaking stuff, and am spending time already spent on "tech debt" that is not at all the fault of your team.

The big problem is that the internet marches on.

• A few years ago, older versions of wkhtmltopdf started breaking on people who didn't change anything...except the servers that it downloaded from switched to a newer version of HTTPS/TLS. You can be sure this will happen again at some point. Maybe years from now, but it'll happen.

• Or maybe it's a new version of Linux, or new hardware architecture will come out that the existing binaries won't work on, and the source code won't compile. Again, just a matter of time.

• Maybe a big security issue gets discovered? Be prepared for no patches.

• Also, wkhtmltopdf's browser engine is frozen in time circa 2015, and there were things that never really worked well in the first place with it. No modern CSS, JS, or Flexbox.

I still think there might be cases where someone only needs the bare minimum of a PDF version of an existing page, or a quick and easy way to ship a PDF feature, where someone might choose to ignore the issues for today (purposely taking on some tech debt) and plop in WickedPDF, but long term, they really should be looking into moving onto something else, IMO.

If you already have WickedPDF all over your app, or need that HTML authoring workflow for your app, then you might consider buying some licenses for PrinceXML and switching to Princely, which WickedPDF borrowed heavily from in it's early days, or using DocRaptor, which is a hosted service that uses Prince under the hood; or switching to Grover, which uses Puppeteer under-the-covers; or Weasyprint.

If you don't, I'd recommend natively building the PDFs with something like Prawn. Sure, it's a pain to have to re-author a fresh template in a different DSL (domain-specific-language), which is more like CSV than HTML, but it doesn't need to spin up a whole new process outside of Ruby, and you can get very precise documents once you get the hang of it.

[rafaeldev]

Hi guys!
I let my hope alive with https://github.com/odoo/wkhtmltopdf project

The odoo is a big company with own bias of strategy of updates but it's looks promissory by the way

[jon-rse]

The binary distribution of wkhtmltopdf doesn't run on Ubuntu 24.
Unfortunately Odoo's project has also been archived, so no white knight is coming from that quarter.

[unixmonkey]

The binary distribution of wkhtmltopdf doesn't run on Ubuntu 24.

@jon-rse It should, using the Ubuntu 22 binary:
https://github.com/zakird/wkhtmltopdf_binary_gem/blob/master/bin/wkhtmltopdf#L46

Let me know if you still have problems with this one.