Almost every LoB developer will come across a task where they need to generate document instances from a template and data (be it a simple data source or a business domain object model), be it mail-merged documents for posting, invoices and quotes, or simple reports for middle management.
I'm working on an ASP.NET WebForms application (I'm not comfortable with MVC just yet, I'll drink the kool-aid when they can convince me of a better alternative to stateful controls) which will need to do such a thing.
I've found a number of options:
Option 1: Generate XML with a CSS (or go simpler and do XHTML with CSS) and send it off to Prince XML which will generate a PDF.
Upside: it means I can use ASP.NET's templating engine directly. Users could design templates using an in-browser WYSIWYG leaving fields in-place, the LoB system populates and transforms the template into an XHTML document and passes that on to Prince which builds the PDF ready for the user to download and print as required.
Downside: Prince costs $3800 per server for commercial deployment and is $950 a year for updates and support. This is not a problem for SaaS applications, but is a problem as the application is also available for local installation, and I don't think clients fancy having to pay more than double the price of the SaaS system just to produce PDFs.
Option 2: Use Microsoft's Reporting system. It can generate PDFs too.
Upside: it's free and built-in to VS, and generates PDFs.
Downside: users cannot generate documents easily, and it's more suited to reports than documents. Finally it only really works well in Internet Explorer 6. Oh, and it's a subclass of the WebControl class, which basically screams "stay away!" as far as I'm concerned.
Option 3: Generate the XHTML+CSS as per Option 1, but let the end-user print it as-is without converting it to PDF. The printed results should be near identical (as CSS strictly defines how printing works) and if users want a PDF they can buy Acrobat or download the free PDFPrinter to install locally.
Upside: easiest to implement and makes it possible to implement Option 1 as funds become available, and leaves the door open for local (non-cloud) users to make their own PDFs too.
Downside: users tend to be stupid (in my case, at least).
Option 4: Use iTextSharp and create the PDF from scratch.
Upside: I really can't think of any
Downside: As iTextSharp (and iText in general) is under the AGPL which would require me to publish the application's source code under the AGPL or pay an unknown amount for an alternatively-licensed commercial version (you have to ask them for a quote). As you have to generate PDFs from scratch it means I can't use ASP.NET's XML-generation infrastructure, it also means template generation is going to be a pain.
All things considered, I think I'll go with Option 3 and then move on to Option 1 as money starts rolling in (if ever, ha!).
Does anyone have any advice or been in a similar situation? What did you do?