Re^2: PDF::Template redesign - I want your ideas!

Every experience I've had with PDFs goes something like this:

The web designer lays out the webpage. It has a bunch of header/sidebar stuff and then there's the tabular report in the content div.
The client likes it, but wants to have something they can print out.
Enter PDF::Template.
Through a series of iterations, a header page, headers and footers, and various layout options appear, as if by magic.
Eventually, the client gets bored of tweaking and asks you to promote to production.

I've talked with people who've used PDF::Template to generate actual PDFs, but I don't know what process(es) they used, if any.

You are right - the lack of use cases is contributing to the lack of direction. Maybe what I'm asking for here is "How do you want to use something that generates PDFs from a layout + parameters?" ...

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^2: PDF::Template redesign - I want your ideas!

Replies are listed 'Best First'.
Re^3: PDF::Template redesign - I want your ideas! by Your Mother (Archbishop) on Dec 01, 2005 at 23:06 UTC
You are right - the lack of use cases is contributing to the lack of direction. Maybe what I'm asking for here is "How do you want to use something that generates PDFs from a layout + parameters?" ... Maybe I do have an idea after all. What would make it the most easy for me (and many others) to use is to allow CSS + HTML to be a feed interface. I would be completely overjoyed to be able to just use the `media="print"` within an HTML page to drive PDFs. I realize this is a daunting suggestion that may not even be a good idea but it would be sheer genius if it could be done. I don't know the first thing about PDF internals but perhaps it might map fairly well...? Or maybe there is already an engine out there that could handle the interchange?	[reply]
Re^4: PDF::Template redesign - I want your ideas! by xdg (Monsignor) on Dec 02, 2005 at 02:20 UTC
What would make it the most easy for me (and many others) to use is to allow CSS + HTML to be a feed interface. I second this idea. As web pages have been getting more and more styled, there's been plenty of thinking and draft specs about how to use XHTML and CSS to specify paged media layouts. E.g. XHTML-print and CSS3-page. Rather than reinventing a way of describing paged media and then coding up how to render it (look, it's a print-driver written in Perl!), I'd rather see an implementation that conforms to even some subset of these emerging standards. What this would do from an interface perspective is really decouple the problem. The PDF generator would need to generate XHTML (using one of several existing back-ends like HTML::Template or TT), be given some CSS (either a trivial default, or something hand-written by the report designer or even something generated from yet another template engine) and just render that following the W3 spec. That would even solve the documentation problem since there's a pre-existing spec for designers to read. For the use case mentioned -- giving a printable report that resembles an existing web page -- the existing templates and CSS would serve as a base. Just throwing that at PDF::Template::Future should produce something not far off from just hitting "print" in the browser, and then the addition of the page-specific stuff should start tweaking it to turn off web-only features and manage the pagination more rationally. That seems much less of a headache than translating it into a substantially different XML format or other mini-language to regenerate a similar-looking report. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^3: PDF::Template redesign - I want your ideas! by samizdat (Vicar) on Dec 02, 2005 at 13:30 UTC
This is the classic case, and I have and have seen many such needs. For text-based stuff as you describe, it's fairly straightforward. One of the groty issues we've run into with all available solutions, however, is that images (logos, etc.) from the web page get re-interpolated and this just makes them look like the dog barfed. Since there are very few pages any more without some graphics, this becomes a more pressing issue. I think converting is more important than manual formatting, but maybe I'm biased because we run into this all the time. As to XML versus CSS versus a little language, I think that if it "just works" for the primary use case, any extra that I/we have to learn in any format is not too much to ask. Don Wilde "There's more than one level to any answer."	[reply]