PDFKit, Rails 3.2, Asset Pipelines

[Jamie Orchard-Hays]

Hey all:

I've been using PDFKit as middleware for a while to generate PDFs in a Rails 3.2 app. A while back I updated the app to use asset pipelines and since then, the PDFGen is broken. PDFs are generated, but the stylesheets are not applied. I've scoured the Web for info, but nothing has sufficed. I even went so far as to temporarily revive an old, saved image at Rackspace just to prove to myself it had worked and that I wasn't nuts.

I can give more info if requested.

Anyone have any experience with this and can give advice? (Maybe it was solved in Rails 4.x versions and I need to plan an upgrade.)

Cheers,

Jamie

[Ken Collins]

Jamie,

I did this last year in a 3.2 app and have that code handy while I type this. Hopefully some of it is helpful!

First, I put all assets that needed to be used in PDF's either in distinct “pdf” directories of the asset pipeline. For example CSS/Sass/HTML would use paths like “pdf/foo.png”. My structure was simple too. I had a app/views/layouts.pdf.erb (http://git.io/vkluH) an app/assets/stylesheets/pdf.css CSS manifest which setup my Sass context.

When I did my work I used v0.10.0-rc2 of wkhtmltopdf. This was the only one that worked for me back then. Not sure if that is still true now. http://code.google.com/p/wkhtmltopdf/downloads/detail?name=wkhtmltopdf-OSX-0.10.0_rc2-static.tar.bz2&can=1&q=

My PDFs used custom web fonts and in my first cut of the work I base64 encoded them due to (http://stackoverflow.com/questions/6721295/google-web-fonts-and-pdf-generation-from-html-with-wkhtmltopdf) that issue. However this did not work completely for me and I had to generate a custom web font via font squirrel. Here they are (http://git.io/vklgg) if you are interested. That gist also has the Sass I used, note asset-data-url to get the base64 too. Remember to add some `depend_on` directives to your root Sass file to help Sprockets bust the cache if these change.

NOTE: Remember to turn on X-Sendfile headers in production.rb: config.action_dispatch.x_sendfile_header = "X-Sendfile”

NOTE: All PDF templates are just raw .erb for dual mime-type HTML/PDF to support functional testing. See http://bit.ly/ib9kPW

Lastly! Here is the PDFKit initializer/freedom-patch I used (http://git.io/vklad). Here you can see my core hack was to leverage the path including “pdf” to get things to work right. A bit janky, but this worked well for us. Please do not pay too much attention to the OurTempfile hacks. I recently learned that Tempfile has builtin in support for this… see here: http://git.io/vklad

Again, hope this is helpful!

 - Ken

--
You received this message because you are subscribed to the Google Groups "RefactorRVA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to refactorrva...@googlegroups.com.
To post to this group, send email to refac...@googlegroups.com.
Visit this group at http://groups.google.com/group/refactorrva.
For more options, visit https://groups.google.com/d/optout.

[Ken Collins]

Whoops, here is the proper URL on how to use Tempfile properly to support file extension:

http://makandracards.com/makandra/13719-ruby-how-to-ensure-a-tempfile-s-extension

[Jamie Orchard-Hays]

Thanks, Ken. Makes me want to give up asset pipelines. Seriously. I have already spent so much time. It's not a good situation when it takes so much to make something like this work with asset pipelines.

[Ken Collins]

I love the asset pipeline. I think the core issue here is a by-product of the way wkhtmltopdf works and is implemented within a rack middleware. It has nothing to do with sprockets fault. 

 - Ken

[Jamie Orchard-Hays]

You are right. I'm just winging. Compiled assets is what we want.

[Jamie Orchard-Hays]

Wondering... if there's a way to write a wrapping middleware that takes care of this problem.

On May 29, 2015, at 11:51 AM, Ken Collins <k...@actionmoniker.com> wrote:

[Keith Bennett]

I'm so glad that Rails is simple. ;)

Sorry, couldn't resist.

- Keith

[John Feminella]

"Look at all the code I'm not writing!"

-- DHH

~ jf

[Jamie Orchard-Hays]

Now, now. No need to bash Rails on the Rails list! :)

For those familiar with the the simple vs easy theme in the Clojure world, I'd say that Rails certainly went for the "easy" side of things in general. That is, make it easy to do the common things. 

One thing I don't like about the implication of "simple vs easy" is that it sets up a sort of pair of opposites, which they are not. I doubt if Rich had that intention, but you can feel it sometimes in community discussions. Simple and easy are orthogonal. The gold is when you can make things simple and easy, no?

Jamie

[John Feminella]

I think Rich's "simple vs. easy" point is not so much that they're orthogonal. Rather, I think he means that starting from "easy" and trying to get "simple" is very difficult, whereas starting from "simple" and trying to get "easy" is much more likely to be successful.

[Jamie Orchard-Hays]

Agreed. Orthogonality is my point. Unfortunately, I think there is a fair number of programmers who have taken it as "simple or easy; one or the other".

On Jun 4, 2015, at 9:21 AM, John Feminella <j...@jxf.me> wrote:

I think Rich's "simple vs. easy" point is not so much that they're orthogonal. Rather, I think he means that starting from "easy" and trying to get "simple" is very difficult, whereas starting from "simple" and trying to get "easy" is much more likely to be successful.