WeasyPrint implementation #218

cveneziani opened this Issue Dec 19, 2013 · 15 comments


None yet
4 participants

That would be great to have a pdfkit implementation of WeasyPrint.

Are there other users of this engine?



miry commented Dec 20, 2013

I think you can use WeasyPrint, to do this just need to remove the default options and set option wkhtmltopdf to use WeasyPrint.

PDFKit.configure do |config|
  config.wkhtmltopdf = '/path/to/weasyprint'
  config.default_options = {
    s: 'http://weasyprint.org/samples/CSS21-print.css'

miry commented Dec 20, 2013

@cveneziani if you want I can build a simple project with pdfkit + WeasyPrint?

Hi @miry

Here is my config:

PDFKit.configure do |config|
  config.wkhtmltopdf      = `which weasyprint`.chomp  # same method as found in pdfkit code
  config.default_options  = {}                        # I prefer to pass options to my initializer.


  • I feel bad using wkhtmltopdf variable name for a non wkhtmltopdf engine.
  • This doesn't work because a default --quiet argument is added

miry commented Dec 20, 2013

You can try my fork miry/pdfkit or check the PR #211 to use pdfkit without option --quiet.

Thanks for your feedback.

@sigmavirus24 What about this issue now that PR #211 is merged?


sigmavirus24 commented Feb 8, 2014

@cveneziani thanks for the ping, I had lost track of this. Would you be amenable to a method on the Configuration object that basically aliases wkhtmltopdf= so that you can do

PDFKit.configure do |config|
  config.pdf_renderer     = `which weasyprint`.chomp  # same method as found in pdfkit code
  config.default_options  = {}                        # I prefer to pass options to my initializer.

It would be a simple fix. (Alternatively, we could make wkhtmltopdf= alias that. :))

Let's say that your pull request is a workaround (since in fact there're nearly 50 occurrences of wkhtmltopdf in code). It could be amenable but that would be great if pdfkit could be independant from wkhtmltopdf or any other pdf generator :)


sigmavirus24 commented Feb 12, 2014

@cveneziani I've been thinking about it. Each pdf generator will probably have different arguments it takes. If we were to make PDFKit that general we'd probably run into more bugs than not. What if we extract a pdfkit-core project and then make pdfkit work the way it does now but require pdfkit-core. Core would require an API from projects that build on top of it to provide PDFKit style projects for other implementations. Would that be a good compromise?

Concerning bugs, I don't see any difference between a general PDFKit and a pdfkit-core.
I think each specific PDF generator can live in a single class (one class per generator).
It might be overkill to have to maintain a core repsitory and several repositories containing just one class.

Generators can live in the same PDFKit repository. For instance, file upload plugins embed several default storage types (eg. file, s3, etc.). Another example would be Exception Notification gem.

What do you think about this? Does this sound a good idea or merely bad examples?


sigmavirus24 commented Feb 13, 2014

@cveneziani my main concern for having everything in one repository is the fact that I am not really a user of PDFKit. I'm maintaining this as a favor for a friend. I'll maintain what's already here: the wkhtmltopdf version of PDFKit but the more adapters there are to other implementations the more I have to maintain that's beyond my interest. It adds a great deal to the work I would have to do to continue maintaining PDFKit. Making something simple that people can extend and distribute is preferable to me.

@sigmavirus24 I understand your concerns but I think this is not a good argument. There're more than 1500 stargazers, 25 watchers and 7 members of pdfkit organization. I think you can count on few of them to update adapters they'll need. To be a maintainer doesn't mean you have to do it all by yourself. If there is a clean core code base and adapters around here, I'll be the person that will implement WeasyPrint adapter. And as soon as this adapter stops working, I'll update it since I need it.

Or we can just say that pdfkit is just a generator that only uses wkhtmltopdf. I understand it too since I'm the only WeasyPrint user :)


sigmavirus24 commented Feb 14, 2014

@cveneziani I appreciate your input sincerely. The difference is I have experience with almost an exactly identical situation. Working on kennethreitz/requests we had several authentication adapters. Enough of them were rarely used by any of the core developers so any bugs reported for them required a significant amount of work on the behalf of the user and we would often wait long periods of time for the author or someone familiar with it to update it. Splitting those off into separate projects has worked very well and allows for faster releases of those libraries than the core library.

I doubt you're the only user who would want to use something other than wkhtmltopdf.

The options I'm thinking of now, though, are different:

PDFKit, can remain exactly the same, but allow for a different way of specifying a command client with options.

Something like:

PDFKit.configure do |c|
  c.register_renderer WeasyPrint

where WeasyPrint inherits from a base and implements an API. Does that sound better?

@sigmavirus24 Thanks for your feedback and sorry for the late answer. I now fully understand your hesitation. Your proposal sounds a good compromise.

sigmavirus24 added the feature label Aug 7, 2014

sigmavirus24 added this to the Version 1.0 milestone Aug 7, 2014

sigmavirus24 self-assigned this Aug 7, 2014

Opening pdfkit up with an API would be great. Since wkhtmltopdf doesn't really work on ARM – neither does phantom.js – it would be great to have more options available. In this case slimer.js. There seems to be a Ruby wrapper for each of these renderers but they're all different and not easily replaced. One project to rule them all would be greatly appreciated and so far pdfkit does the best job :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment