Tech Off Thread

10 posts

Let's talk about reporting and document generation

Back to Forum: Tech Off
  • User profile image
    W3bbo

    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?

  • User profile image
    CarlB654

    I've been using DocRaptor.com. It's a web app that lets you convert html to pdf (or xls) - it uses Prince XML, but it's waaaaay cheaper. They even have a free plan. 

    I've tried other options, but DocRaptor has been the easiest. 

  • User profile image
    Dr Herbie

    @W3bbo: Well, our main UI is desktop, and any web UI is of lesser status.  We already use Crystal Reports or Reporting Services in the desktop system to generate/print reports.  

    For Web use I believe we generate the report on the server using the same code as the desktop system, save as a temp file (Crystal can export PDF, not sure about Reporting Services) and send it to the user as a web response.  Report generation is NOT done as a web process, but as a back-end process initiated through the Web UI.

    Our reports are all 'canned' reports -- e.g. user selects specific reports from pre-defined list, so we have little/no UI for them (other than user selecting various report parameters and filters).

     The web systems that include reporting have low user counts (less than 10 users at once I suspect), so the processing load on the server is not too high and it can process the reports without slowing down.

    Herbie

     

  • User profile image
    W3bbo

    , CarlB654 wrote

    I've been using DocRaptor.com. It's a web app that lets you convert html to pdf (or xls) - it uses Prince XML, but it's waaaaay cheaper. They even have a free plan. 

    I've tried other options, but DocRaptor has been the easiest. 

    Oooh, DocRaptor looks perfect. Thanks! Big Smile

  • User profile image
    ScanIAm

    I haven't used SSRS since VS 2005, but back then, it just wasn't ready for prime time.  Specifically, if you packaged up a bunch of sub-reports into a larger report, page numbering wouldn't work the way the client wanted.  For a while, I had hoped to generate reports in Word using WordML and then printing them to PDF would suffice, but word has no concept of pages which stymied us when it came time to display information that was page appropriate (are you noticing a pattern?)

    If the data you are attempting to generate is simple and you don't bump into the need to know exactly what page you are on, I'd suggest using WordML (a.k.a. OpenOfficeXml...you don't need word for that) to generate the files, and if you then need to see them in PDF format, you can programmatically ask word to 'print them to PDF'.

    That said, if you wanted to make some real money, you could just learn the PDF langauge and build the files yourself Smiley

  • User profile image
    itsnotabug

    have you looked at pdfsharp? i think their license is a little less restrictive than itextsharp: http://pdfsharp.com/PDFsharp/

     

  • User profile image
    W3bbo

    , itsnotabug wrote

    have you looked at pdfsharp? i think their license is a little less restrictive than itextsharp: http://pdfsharp.com/PDFsharp/

     

    It's not a "little less restrictive", it's the MIT License which is about as unrestrictive as you can get before you reach Public Domain.

    PDFSharp looks alright, but it is a PDF library as opposed to a converter, which means I'd have to define documents from scratch rather than make use of the existing (and well-understood, at least to me) CSS page layout system which Prince uses.

    But thanks for the tip; if PDF/document generation becomes a major feature of my product then I'll definitely look into using this as opposed to paying per-document with DocRaptor.

  • User profile image
    pgfearon

    @W3bbo: An alternative approach could be to use XSLT with EXPath extensions and templates to produce Word, ePub or XPS documents instead of PDF.

    There a blog here with a couple of videos on using EXPath/XSLT 2.0 with a Word template combined with OData.

    Currently, the only public standalone implementation for the EXPath ZIP module is in Java, I use an 'in house' .NET version. (If there were interest in the .NET version, I could make this available as a dll (with source and permissive licence) for use with the Saxon.Net XSLT processor.)

     

     

  • User profile image
    itsnotabug

    migradoc also looks promising.

    http://www.pdfsharp.net/MigraDocFeatures.ashx

    it targets pdf, word, html, rtf, xps.

  • User profile image
    W3bbo

    Lloyd (who remembers him?) suggested to me in an IM that I check out wkhtmltopdf, which is similar to Prince in operation, but rather than use its own CSS layout engine, it uses WebKit's, which is quite ingenious.

    It's under the GPL, and I understand shell execution doesn't count as linking so I should be in-the-clear.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.