views:

495

answers:

4

EDIT : I completed this project using ABCpdf. For anyone interested, I love this product and their support is A+. Everything I listed as a 'Con' for the HTML -> PDF solution was easily doable in ABCpdf.


I've been charged with creating a data driven pdf report. After reviewing the plethora of options, I have narrowed it down to 2. I need you all to to help me decide, or offer alternatives I haven't considered. Here are the requirements:

  1. 100% Data driven
  2. Eventually PDF (a stop in HTML is fine, so long as it is converted)
  3. Can be run with multiple sets of data (the layout is always the same, the data is variable)
  4. Contains normal analysis-style copy (saved in DB with html markup)
  5. Contains tables (data for tables is generated at run-time)
  6. Header/Page # on each page
  7. Table of Contents
  8. .NET (VB or C#)
  9. Done quickly

Now, because of the fact that the report is going to be generated with multiple sets of data, I don't think a stamped pdf template will work since I won't know how long or how many pages a certain piece of the report could require.

So, I think my best options are:

  1. Programmatic creation using an iText-like solution.
  2. Generate in HTML and convert to PDF using a third-party application (ABCPdf is the tool I have played with so far)

Both solutions have their pro's and con's.

Programmatic solution:

Pros:

  1. Flexible
  2. Easy page numbering/page header/table of contents
  3. Free

Cons:

  1. Time consuming (to write a layer on top of iText to do what I need and keep maintainable)
  2. Since the copy is already stored in the db with html markup, I would have to parse through the data before I place it into the pdf, ensuring I don't have to break the paragraph into chunks so I can apply bold, italic, underline, etc. to specific phrases. This seems like a huge PITA, and I hope I am wrong about that assumption.

HTML -> PDF

Pros:

  1. Easy to generate from db (no parsing necessary)
  2. Many tools for conversion
  3. Uses technology I am already familiar with
  4. Built-in "Print Preview" - not a req, but nice

Cons:

(Edited after project completion. All of my assumptions were incorrect and ABCpdf is awesome)

1. Almost impossible to generate page headers - Not True
2. Very difficult to generate page numbers Not True
3. Nearly impossible to generate table of contents Not True
4. (Cross-browser support isn't a con; Since its internal, I can dictate what browser to use)
5. Conversion tool quirks - may not convert exactly as rendered in browser Not True
6. Overall, I think it would be very hard to format the HTML exactly as I would want it to appear/convert to PDF. Not True

That's it - I need the communitys help in deciding which way I should go. I might be wrong about some of my Pro/Con assumptions. If I am, please tell me. All thoughts and suggestions are welcome and appreciated.

Thanks

+1  A: 

Depending on which platform you are using and targeting, you might want to consider a reporting solution. These are not perfect but the one thing they do give you is the ability to write a report once and then render it in HTML, PDF, or even Excel.

Usually they also provide an editor that helps you design the report and make it look just right. They provide things like paging, headers, footers, graphs, etc. They also provide an API that you can use to programatically create and run the reports.

I've used Reporting Services in a MS environment and Jasper Reports in a Java environment with good results in both. I'm sure there are other options but these are the ones I've been able to use successfully.

TskTsk
+1  A: 

I think that if you have a full version of Adobe Acrobat Pro, it comes with Adobe Live Cycle. You should be able to produce reports generated from a database from it. It will give you everything you need in formatting since you will create the report from scratch.

You can create a database connection to an OLE database that will feed data to your form fields. You select the tables to be used, any stored procedures that will run, any queries, and then the data will appear on one of the pallettes in the designer.

You can also use Web Services (WDSL) to receive and process commands and return the results to the form.

Either way, you would bind fields to your data source and then the data would be displayed in your form.

If you're willing to do a little .NET work there's this:

http://www.dotnetvj.com/2009/05/populating-pdf-from-aspnet-using.html

tahdhaze09
I think your solution would work well for a PDF with pre-determined fields (sort of like a Tax Form or an invoice.) What I am trying to do is generate a report where I have no idea how much content I am working with on any given run of a report. I don't think a PDF-template approach will work - However, I will look into this again.
IniTech
I think you could still pull it off with a stored procedure that will format, and maybe a page-wide text field? Just pulling stuff from mid-air. Do you know what tables you're pulling the data from in the DB?
tahdhaze09
Yes, I know all the applicable fields and tables. I think I'm going the HTML -> PDF route. I'll post back with my results. Thanks for the help.
IniTech
A: 
Ms2ger
+3  A: 

Decided on using an approach similar to the one used at http://alistapart.com/articles/boom

Using ABCPdf instead of Prince for the eventual HTML -> PDF generation.

Anyone who is interested in the same thing, feel free to message me about this approach.

IniTech
Hi, I am interested in how complex you PDF reports are, would it be possible to get more info and see examples of the PDF report and/or code? My email address is on my profile (not sure how one contacts other users on here)
Mark Redman