After some googling, irc'ing, and mailinglist'ing It seems that rfpdf is destined to die, I vote move to prawn, which appears to have a future :)

Switching to prawn would work for me, though I was also thinking about if we couldn't use the library based on webkit/pdfkit (can't remember the name) which would enable us to just "dump html to pdf", thus maybe working with themes for example. Not sure if said library didn't have C bindings though.

Looks like Toshi changed redmine over to TCPDF fyi: http://www.redmine.org/issues/8312

Felix Schäfer wrote:

Switching to prawn would work for me, though I was also thinking about if we couldn't use the library based on webkit/pdfkit (can't remember the name) which would enable us to just "dump html to pdf", thus maybe working with themes for example. Not sure if said library didn't have C bindings though.

I think you're thinking of PDFKit which requires wkhtmltopdf (WebKit HTML To PDF) which looks like it's Mac/Linux only.

Muntek Singh wrote:

Looks like Toshi changed redmine over to TCPDF fyi: http://www.redmine.org/issues/8312

TCPDF is still part of RFPDF.

Eric Davis

Eric Davis wrote:

Felix Schäfer wrote:

Switching to prawn would work for me, though I was also thinking about if we couldn't use the library based on webkit/pdfkit (can't remember the name) which would enable us to just "dump html to pdf", thus maybe working with themes for example. Not sure if said library didn't have C bindings though.

I think you're thinking of PDFKit which requires wkhtmltopdf (WebKit HTML To PDF) which looks like it's Mac/Linux only.

Yes, and that's what I feared, yes.

Eric Davis wrote:

Felix Schäfer wrote:

Switching to prawn would work for me, though I was also thinking about if we couldn't use the library based on webkit/pdfkit (can't remember the name) which would enable us to just "dump html to pdf", thus maybe working with themes for example. Not sure if said library didn't have C bindings though.

I think you're thinking of PDFKit which requires wkhtmltopdf (WebKit HTML To PDF) which looks like it's Mac/Linux only.

FWIW: I believe it supports Windows as well. (There is a Windows installer here: http://code.google.com/p/wkhtmltopdf/downloads/list).

I'm playing around w/ wkhtmltopdf in Chili for a small task at work...seems pretty handy so far (just trying to get it back on the table as an option ;-)).

Tom Kersten wrote:

FWIW: I believe it supports Windows as well. (There is a Windows installer here: http://code.google.com/p/wkhtmltopdf/downloads/list).

I'm playing around w/ wkhtmltopdf in Chili for a small task at work...seems pretty handy so far (just trying to get it back on the table as an option ;-)).

Thanks, I must have missed that. Let us know if you can share any of the code for it. I'm really interested in something complex like the issue export or gantt export.

Eric Davis

Eric Davis wrote:

Tom Kersten wrote:

FWIW: I believe it supports Windows as well. (There is a Windows installer here: http://code.google.com/p/wkhtmltopdf/downloads/list).

I'm playing around w/ wkhtmltopdf in Chili for a small task at work...seems pretty handy so far (just trying to get it back on the table as an option ;-)).

Thanks, I must have missed that. Let us know if you can share any of the code for it. I'm really interested in something complex like the issue export or gantt export.

Eric Davis

Sure. I'll spend a bit of time and report back...likely asking for some input in IRC or on the Twitters on what level of complexity you are looking for. I believe there are some issues w/ things like pagination on tables which are handled more elegantly in Prawn. Time will tell...

Here's an update on what I've found w/ regards to using wkhtmltopdf...for those interested...

What I've done so far is looked at what I believe to be the two primary tools for integrating the wkhtmltopdf executable with Rails: PDFKit (gem) and wicked_pdf (plugin).

A few resources I used to get up & running with both are:

1. http://railscasts.com/episodes/220-pdfkit
2. http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html
3. http://metaskills.net/2011/03/20/pdfkit-overview-and-advanced-usage/
4. http://mileszs.com/blog/2009/06/17/wicked-pdf-plugin.html

My goals at this point were to just figure out the differences between the two approaches. Longer-term, I want/need to be able to generate PDFs with styled headings/footers for individual wiki pages and ideally "psuedo-booklets" (a collection of content from several wiki pages with an introduction page and "cover page"), so that was in the back of my mind as I worked through them. I know exporting Issues will be necessary/desired as well, but I didn't play with that at all yet. It may be naive, but I don't think there will be any big differences in the requirements between the wiki-page export & issues though...

Overview of the options (for the unfamiliar)¶

1. PDFKit (repo)
   1. The gist: PDFKit provides a drop-in solution for rendering an existing page to PDF. You basically add it to your environment.rb or Gemfile, add the middleware they provide to the list for your app, and put ".pdf" at the end of a URL...and you have that page in PDF format...just as you see it. You can customize the output by setting the gem to make "media" requests...and then using the @media option in your stylesheets to override the default look & feel of the standard HTML view. You can filter the actions which are allowed to be exported to PDF in the config of the gem (in an initializer). You customize the options of your PDF rendering via meta tags in your view template (think "footers", "margins", "page-size" options)
   2. How it works: The "typical" way to use PDFKit seems to be to use the middleware they ship with the library. The middleware basically intercepts any ".pdf" request and says "Cool, I'll strip that '.pdf' off the URL and just make a standard HTML request to that same URL in your app. Whatever HTML it returns, I'll throw into a PDF w/ the wkhtmltopdf executable." (it sets a few headers & such in the process). If you want to get away from the middleware approach, the way to use it seems to be to handle the request with the standard format blocks (format.pdf) and use the "render_to_string" method in your controller action...passing in the necessary params to PDFKit.new (url to your stylesheets, template, footer, layout, etc).
2. wicked_pdf (repo)
   1. The gist: This is a plugin which basically wires up the 'format.pdf' block and "render" method with a way of rendering the output of an action as a PDF file. Essentially it makes the "manual option" of PDFKit more "similar" to the standard Rails rendering conventions. There are just under a million options you can pass in to customize the PDF (versus PDFKit's meta-tag approach).
   2. How it works: There isn't much to say here, there is a pretty clear mapping of options you can pass in to the "render" call and what wkhtmltopdf supports on the command line...

Notable items¶

1. PDFKit
   1. The Good: If you want to roll out application-wide PDF export...for every page...this is hard to beat. You basically drop it in...and it works. If you do some @media styles, you can get a decent export with essentially zero changes to any templates and/or controllers.
   2. The Less-Good: There does not seem to be an easy way to render a completely different view template. You can change the layout, but I couldn't find an elegant way to change the view template. I threw in a couple hacks to detect if a request was coming in from PDFKit and then switched the view template within the format.html block depending on that...which is ugly. Going back to my original goals, I was leaning towards using a completely separate layout and view template...and I couldn't figure out a nice way of doing that with PDFKit. The articles I looked over seemed to assume you wanted to use the same layout for HTML and PDF and just handle the rendering differences via the @media CSS filter. I get the sense that I must have missed something in this setup because that doesn't seem right to me...but...anyway. In the code I posted (links below), you will see I didn't name the layout template 'pdf.pdf.html.erb', because I was manually switching it to a different layout entirely in a before filter...
2. wicked_pdf
   1. The Good: If you want to handle the rendering similar to how you do other formats...on a per-controller, per-action-basis...this is the way to go, I think. Although there are a massive number of options you can pass in, it's pretty straight-forward and I only ran into one "bug", which I'm not sure falls on wicked_pdf or not (may be wkhtmltopdf)...which was rendering a footer line on the first page. It renders find on all pages but the first...not sure why at this point. I struggled a lot more with PDFKit when it came to customizing things for a specific view. Again, I may have approached using PDFKit wrong, so, input on that is welcome...
   2. The Less-Good: You can't just drop it in on the application without touching any controllers (at least)...and if you want to have tailored views, you obviously have to implement them as well. Of course, if you just want to handle it via the @media filter, the controller changes are minimal and there are no view changes necessary. However, if you want to do this on lots of pages, you might as well go with PDFKit.
3. Both options
   1. The Good: The output looks great, it's easy to style the output, and you can leverage things like JavaScript in the rendering. This is a big win over alternatives I've seen, such as DocPu (and Prawn), as we use MathJax at work and being able to include the "fancy" equations it generates will be a big win. I haven't tested that specifically at this point, but I can't see why it wouldn't Just Work(tm)...
   2. The Bad: You need to have your system set up with multiple application server processes running to export PDFs, because the original request has to wait for wkhtmltopdf to request other views/assets to render the HTML...which is then converted to a PDF. I assume this would be fine on any production installations, but, it's just something people will need to know when in development-mode. Also, every once in a while the rendering fails. I'm not yet sure if it was purely a development-mode issue (I wasn't starting up in 'production' most of the time), or a bigger problem. It's rare, and refreshing the page made the request go through fine, but I thought I would mention it...

If you want to see a few code samples I committed while I was messing around with this, you can check 'em out here:

1. pdf-pdfkit-no-middleware
   1. I was playing around with not using the middleware and using the "render_to_string" option, mostly because I was looking for a per-page level of flexibility
2. pdf-pdfkit-using-middleware
   1. I wanted to see how the middleware "felt". You will see some hacks (well, those are in all three versions ;-)) in here to make it bend to my desires...using a different layout, etc.
3. pdf-wicked_pdf
   1. ...I convert the PDFKit setup to use wicked_pdf...

I don't have tests around any of this...but thought I'd throw those spikes up in case people just wanted to see what I was trying to outline above.

Let me know if you have any thoughts or questions on what I've outlined.

I have migrated the spike I posted above to a plugin (gem) called chili_pdf. It requires a2-line patch to the ChiliProject codebase in order to work as it is implemented today¹. My goal was to leverage the standard "respond_to" block and add a ".pdf" extension to a Wiki page with a reasonable-looking export which allows for simple customizations (custom headers/footers, easy to style, etc).

I haven't released an official gem yet, but v0.1.0 will be coming soon. Until then, I thought people may be interested in seeing the codebase and contributing to a plugin outside of the ChiliProject repository until some of the implementation details have been figured out...or at least knowing it was out there.

¹ I have submitted a pull request with this patch. The patch removes an explicit render from the controller and updates a partial call to have the full-path to the necessary partial template.

PDFKit sounds good, especially with the middleware "PDF anything" approach. But customizing it sounds like a pain. wicked_pdf might work since it's similar to how we currently do things (respond_to pdf and generate the file).

I'd like to hear from other people still.

Eric Davis

I have pushed out v0.1.0 of the chili_pdf gem I mentioned above. You can find out more about it here if you like. I will be adding in a few refinements like header/footer markup markup next. Feel free to throw comments in here or at me on the twitters if you like...

FYI: v0.2.0 has been pushed, which fixes a few little rendering issues & such.

Also, I won't spam this topic anymore with updates like this, as I am sure it's annoying for many of you. ;-)

I have stubbed out what I expect to do release-wise into milestones on the Github project page and you can always find the current stable release on Rubygems. I'll throw an update in here after the currently slated releases are out. Obviously ping me either on this thread or one of the other mediums mentioned above if you have some thoughts and or requests...

Tom Kersten wrote:

Also, I won't spam this topic anymore with updates like this, as I am sure it's annoying for many of you. ;-)

I'm fine with it. If you're doing active development on a feature we are considering, having an update of how it's going each release would be a good thing. But I'm also of the opinion that over-communication is better than under-communication.

Obviously ping me either on this thread or one of the other mediums mentioned above if you have some thoughts and or requests...

I have an invoicing plugin that I'd like to try this on. Right now I just have a cleaned up view that removes most of the theme using CSS which I print out to a PDF. Might be a simple test to see how this works.

Eric Davis

Eric Davis wrote:

Tom Kersten wrote:

Also, I won't spam this topic anymore with updates like this, as I am sure it's annoying for many of you. ;-)

I'm fine with it. If you're doing active development on a feature we are considering, having an update of how it's going each release would be a good thing. But I'm also of the opinion that over-communication is better than under-communication.

Noted. I will announce new releases on this thread as well then.

Obviously ping me either on this thread or one of the other mediums mentioned above if you have some thoughts and or requests...

I have an invoicing plugin that I'd like to try this on. Right now I just have a cleaned up view that removes most of the theme using CSS which I print out to a PDF. Might be a simple test to see how this works.

Cool. As I mentioned, I have outlined my "planned" approach into "v0.x" milestones on Github...and I don't have anything about "issues" at this point. Therefore, adding to the existing plugin would be both awesome, and likely easy to merge into the codebase. I'm pretty happy with how it feels at this point, at least with regards to the wiki page exports. I think being able to experiment in the plugin is a big win.

Some bad news is that my laptop died a few days ago and is in the shop for repair...I am in the process of getting back up & running on a temporary machine, but it has delayed my original release plans (so, no v.0.3.0 stuff will be released today :-().

-tom

I pushed v0.3.0 of the ChiliPDF gem today. Here are the updates:

• New features
  • Added header/footer support [closes #2]
  • Implemented 'footer_enabled' and 'header_enabled' settings to control whether footers/headers are included [closes #3]
  • Added 'dynamic' content which can be used to customize the header/footer sections of exported PDFs (see TokenManager and TokenString for details) [closes #4]

• Minor enhancements:
  • Added testing harness
  • Updated layout to include any :header_tag content_for blocks
  • PDF content was previously not being wrapped in PDF layout...fixed
  • Threw in a fix for ul->li's showing numbers [closes #6]
  • Added Formatter class which will be used for managing PDF formatting

...and some screenshots of how it looks at this point: http://www.flickr.com/photos/tomkersten/sets/72157626827940413/

Next up is support for images (wkhtmltopdf does not render assets with relative URLs).

Feedback is welcome...

Big release today (imo). Added full image support and made it pretty simple to add your own custom JS or CSS to style PDF exports. Here are a few screenshots of what it looks like.

I think it's approaching a "solid" state for basic wiki PDF exports. Let me know what you think...

Here are the 0.4.0 release notes:

=== 0.4.0 / 2011-06-18

• Simplified customizating styles of of exported PDFs. Added ability to insert custom CSS and JavaScript into the DOM before the PDF is rendered [closes #12]
• Added support for images in wiki pages to be exported in PDFs [closes #10] (Thanks to @roykolak for the code review!)
• Added support for rending the HTML used to create the PDF by passing "as_html=true" in as a URL param (eg: /Page.pdf?as_html=true) [closes #9]
• Added nokogiri as a dependency to get around requests for protected assets (images, etc) (see issue #10 for details)

• Fixed image-sizing issue when resolution of image is wider than the exported PDF [closes #11]

I released a minor version today (0.4.1)...basically it adds some styling updates (for pre blocks) and support for a custom logo on the first page of exported PDFs.

Here are some screenshots.

Any news about changing backend of PDF export?