Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

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

by Your Mother (Archbishop)
on Dec 01, 2005 at 23:06 UTC ( #513476=note: print w/replies, xml ) Need Help??

in reply to Re^2: PDF::Template redesign - I want your ideas!
in thread PDF::Template redesign - I want your ideas!

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?

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

Replies are listed 'Best First'.
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.


    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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://513476]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (1)
As of 2021-10-20 19:34 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (81 votes). Check out past polls.