in reply to Re: Generating beautiful reports
in thread Generating beautiful reports

How would a PDF-generating lib make difference in this case? How is:
my $pdf = new PDF::Create(...);
my $root = $pdf->new_page('MediaBox' => [ 0, 0, 612, 792 ]);
my $page = $root->new_page;
$page->stringc($f2, 40, 306, 426, "PDF::Create");

[download]
...better or easier to handle than:
$im = new GD::Image(100,100);
$image->stringFT($color,$font,10,0,123,321,"GD")

[download]
?

Replies are listed 'Best First'.
Re: Re: Re: Generating beautiful reports
by simon.proctor (Vicar) on Apr 09, 2002 at 11:35 UTC
    My post covered two topics using PDFs instead of images and potential options for making that generation easier. If you want a reasoned argument about why using PDFs would be better than images then I suggest you firstly do a super search and then, if not satsified, post a meditation on the matter. Its a bit OT so you may want to label it as such.

    As for the generation of the PDF being easier, I didn't specifically cover any particular method of code generation but considered it from a higher level. Ease is in the eye of the beholder. From a personal standpoint I'd either write a command line java tool using the Cocoon libraries for XSL-FO and build a docbook template. Or I would build a system that could automatically generate the right output code and then process that. The end result for both of these would be significantly simpler to use and maintain. But as you should know by now, theres more than one way to do it.

    Update In response to Kappas question (which may be below your node depth) I would personally go for an XML approach if I knew I was going to be deploying this system on a large number of projects. I would produce a template that had template toolkit processing instructions in it and would populate it from the variables returned from the CGI environment. For that I would use CGI.pm.

    Once the template has been populated, I've then got a nice generic text representation of my data which I can process by passing this to my processing object. This processing object would, initially, use a Java based commandline tool with XSL-FO. This would allow me to have a demonstration system running quickly but I can then change the generation at a later stage by changing the processing object internals if I really need to. If speed was a requirement, I'd consider doing the PDF generation using the same library under Tomcat.

    I'd use the information from the Apache XML project to do it.

    Please note, this is just how I would do it and I've put it here cos I was asked specifically. I'm not saying this is the only way or the best way. Its just my way (till I see a better one!).

    HTH :)
[reply]
      Excuse my possible being rude, that's probably due to my poor English :) This was unintended. Could you please elaborate a little on your suggestions? How would you solve a problem of templates? Would you teach your designers to output XML according to your standards? Or would you write a visual template composer for them to use? Do you have practical good experience with XSL:FO in comparison to LaTeX and the like?
[reply]

In Section Seekers of Perl Wisdom