PdfKIT

[jonsgreen]

I was wondering whether you guys had heard about this:
http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html

[Gregory Brown]

On 6/15/10 9:43 PM, jonsgreen wrote:
> I was wondering whether you guys had heard about this:
> http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html

I tweeted about this earlier today:
http://twitter.com/seacreature/status/16257687342

That post is incredibly unreasonable, since it does not show a
comparison to Prawn for table output.

In general, I feel like html2pdf is a great idea when you actually want
html to pdf.

But for generalized document generation and typesetting: I think it'd
be easy to generate a ton of PDFs that any html2pdf tool would choke all
over itself on (except maybe Prince).

I'm going to wait until I'm no longer irritated by that post and write
up my thoughts on this. It's mainly that this isn't the first time I've
seen someone announce how some HTML2PDF tool was soooo much better than
Prawn, but that comparison is based on a very narrow subset of what
Prawn is useful for.

(For what it's worth though, I don't have my doubts that html2pdf tools
give acceptable output for much less effort in certain situations)

-greg

[Randy Parker]

On Tue, Jun 15, 2010 at 11:00 PM, Gregory Brown <gregor...@letterboxes.org> wrote:

On 6/15/10 9:43 PM, jonsgreen wrote:
> I was wondering whether you guys had heard about this:
> http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html

In general, I feel like html2pdf is a great idea when you actually want
html to pdf.

My app has to fill in thousands of legal forms, each with dozens of fields.  There is no way an html convertor can provide the sub-millimeter accuracy I need for each field.

But I also send out general purpose pdfs that aren't so picky.  Maybe pdfkit would make some of those simpler...  though they are so straightforward to write in Prawn that I'm having a hard time picturing how they could really get much smaller.  For some layouts, CSS is much harder to use than a coordinate system.

Depending how the Prawn tables end up, maybe pages with titles, text, and tables will be easier in pdfkit.  Especially pages using Rails-like layouts

- Randy

[Gregory Brown]

On 6/15/10 11:39 PM, Randy Parker wrote:

> Depending how the Prawn tables end up, maybe pages with titles, text,
> and tables will be easier in pdfkit. Especially pages using Rails-like
> layouts

Yeah, in the context of Rails, I can see a lot of 1 page PDFs benefiting
from html2pdf tools.

But I wonder how it handles pagination, if at all. If anyone feels the
urge, please try it out and post some examples back here.
Unfortunately, while the article had links to some PDFs, there wasn't
much code to bite into. If we had a bit of that going on, it would be
easier for me to chill out :)

I'd really love to make up a "When to use Prawn vs. When to use HTML 2
PDF" guide. Could be helpful to our users.

-greg

[Daniel Nelson]

> But I wonder how it handles pagination, if at all.  If anyone feels the
> urge, please try it out and post some examples back here.

I haven't tried PDFKit, and have neither the time nor the urge now,
but I have used Prince XML, in conjunction with Princely, so I can
comment there.

Pagination worked fine for many purposes. The project with which I
used Prince included tables that extended onto new pages. They flowed
fine from page to page. The page-break CSS elements work. Prince
enables the inclusion of portrait and landscape orientation in the
same document.

However, I don't think it would be possible to do conditional page
breaking, as is possible in Prawn via grouping, or as we are aiming
for with the new delayed rendering (eg: if only one row of the table
fits on this page, move it to the next). And multi-column documents
where text flows from left column to right, and then on to the next
page, aren't achievable in HTML unless there is something I don't know
about (I haven't looked into the HTML specification for dealing with a
paginated environment).

The big win with Prince (or perhaps PDFKit) is when you need to
provide people with the ability to download a PDF version, or print a
nice version, of a page that you are already generating as XHTML +
CSS. The money saved by only needing to hire someone to write HTML +
CSS, rather than someone to write HTML + CSS and someone else to
generate the Prawn or whatever else that corresponds to the HTML + CSS
can easily surpass the $3,800 fee (which is a one-time fee, not an
annual license) for Prince XML. Especially if the appearance of those
documents is changed frequently or there are many different document
layouts. Plus, there is less room for the PDF output to stray from
what people see in the browser, which can be important to a company.

Prince XML + Princely was amazingly true to the original HTML + CSS.
The only adjustment I needed to make that was due to Prince was to
reduce the font size declared in body because printed output didn't
need as large a font as on-screen. Princely made it easy to do this
with the application of an additional stylesheet to override the
screen style.

But for the project I'm doing now, the PDF output I need cannot be
rendered in HTML, so no HTML to PDF converter would work. Prawn does.

-Daniel

[Kristian Mandrup]

I have also been evaluation PdfKit against Prawn. As you say, there
are usage scenarios for each. I started a project called Howrah, which
is still in a kind of spike stage, but the design is pretty much
there. Just haven't had time to work on it lately.
This project is called Howrah and is supposed to be a very flexible
engine powered by Prawn, to convert Html (or potentially any
traversable model) to Pdf with support for good pagination control
etc, adding index, page headers and footers etc.

The project consists of Howrah-bridge which can be seen as the main
"controller", which given a html text converts it to a Nokogiri model
and starts processing from the html root node. It takes advantage of
Nokogiris support for decorating its model with extra functionality
(modules). The Documkent, Text and Element nodes each have a process
method added. So it iterates and calls process on each node, for
document and element nodes it iterates child nodes. When an element is
"processed" it calls a TagProcessor which handles css styling and
finding an appropriate registered processor for that particular tag
name (which you can define yourself to override the default).
This processor has responsibility to capture the state of the element
and pass this off to a registered Renderer for the same tag using same
pattern as for Processor.
The Renderer takes the state and determines which prawn commands
should be rendered given this state. These prawn commands are stored
and are only in the end sent to a PRawn Command Center, where they can
be either sent to a pdf document or returned (fx for spec assertion)
or filtered or whatever you like.

Would love if someone could help me finish this or come with some good
suggestions etc. The first step is to define and spec the 'howrah-
renderer' project, and make sure each tag has a good default renderer
defined. The framework for this is there. Then each renderer should
specify the contract that the respective processor must uphold.
Then on to finish the 'howrah-processor' project using this input.
Then finally stitch it all together. For the css to prawn styling I
have a separate project which is mostly in place, except I need prawn
to support the new Document Layout for a box like model, and I added
support for more text box styling such as background color etc.
What do you think?

Kristian