This application is very, very simple; it's a practically the starting skeleton of a modern Rails/Devise application.
One useful reason to bookmark it: it's a pretty good how-to for "any web application whose purpose is to spit out PDF files that need to follow a specific format". There are a LOT of business processes that work like that.
You lose control of pagination when you do this, but, more generally, we're talking about business processes where things need to look exactly the way they usually do.
That said: I used to do the same thing, and it works pretty well.
I managed to get the pagination I needed via judicious use of "page-break-before: always", but yes, this is more a strategy for "I need to programatically generate PDF files" than "I need to generate PDF files which look exactly like this".
> One useful reason to bookmark it: it's a pretty good how-to for "any web application whose purpose is to spit out PDF files that need to follow a specific format".
As others have pointed out, the (not really open source) license doesn't allow any uses for other purposes.
Read your comment (and other's) about the PDF filling and got interested into looking at the source.
I think doing it this way is wrong. It's essentially the same thing as putting your code and HTML together in a PHP file for example.
When the format of a PDF file is fixed and must be filled computationally, I'd advise to add PDF fields to the original and fill those by name through API calls instead of using coordinates.
That way, you can hope to write your code once and update the PDF when necessary.
But OK, it's all pretty dumb and maybe not worth a mention at all.
I think there's two things going into that: first, that Prawn's support for PDF forms is janky, and second, that the way they implemented the precise look/feel of the original PDF form was to use a cut-down version of the original as a template.
Which is a good thing to know how to do; I've had to deal with forms that were very annoying to reproduce with the tools available to Ruby programs.
I used Apache Fop (http://xmlgraphics.apache.org/fop/) to convert XML to PDF at a previous job. It was extremely painstaking work. On the other hand, it gives you a lot of fine-grained control over the appearance of your PDF.
I’ve found ODF is a very convenient format for generating documents. It has a little bit of a learning curve, but you can edit your templates in Libre Office and fill it using any kind of simple templating solution.
It really is quite neat — if you define all your styles declaratively then the markup you touch is very clean and simple, e.g. something like this:
I too used Fop at my last $job to generate PDF files. As you said, the source was extremely tedious to write but you can't beat FOP for the precise control. I would first look to other solutions, since they can be faster, but FOP will always come through.
Yeah, it changes the game when you need to fill out a pre-existing PDF form with user-supplied data (as opposed to free form PDF generation). In my experience, you pretty much have to use a Java library (such as iText) for this. So for a Rails app, that means JRuby, queue to a Java daemon processor, or something along those lines.
One useful reason to bookmark it: it's a pretty good how-to for "any web application whose purpose is to spit out PDF files that need to follow a specific format". There are a LOT of business processes that work like that.