[Struts Recipes] PDF Recipe

[Jason Menard]

Hey Guys,

I just got your book yesterday from Manning for review. I like what I see so far, but I have a question regarding your recipe on generating PDF. In your book, you choose iText as your API for PDF generation. With XSL-FO being so common for PDF generation (dare we call it a de facto standard?), why was there no mention of it in this section as an alternative in conjunction with FOP? This one really puzzled me as XSL-FO is, in my opinion at least, not only more generally accepted, but more flexible.

Was this a case of you guys feeling that iText is really more suitable for the task, was it a case of iText being easier to illustrate more succinctly than XSL-FO, or something else?

[George Franciscus]

This is a really good question. A couple of years ago I create a PDF with Apache FOP http://xml.apache.org/fop/ It worked, but I had a couple of misgivings.

1. You need to position your data in XML for the transformation. Therefore, there is the overhead to create XML. That was extra work I would rather not have done. If your data is coming from the Model as XML, then there is an argument to using XSL-FO � but IMO not a strong one.

2. You need to create an XSL style sheet. This means that the developer needs XSL skills. More importantly, the maintenance staff needs XSL skills. Since the developers already know Java, why develop a second skill set?

3. Its was very verbose. I was creating a PDF to present a policy change to insurance brokers. It was quite a lengthy style sheet by the time it was done. It didn't look too maintainable. I can still see the look of horror on the maintenance developers face.

4. I was a little worried about performance. I guess this is somewhat related to #1. Creating XML and then applying a style sheet doesn't perform all that well.

I had the opportunity to do the same type of thing on another project. This time I looked for something that would allow me to do the whole thing in Java. iText had critical mass and was easy to use. I was able to create a PDF in just a few minutes. I found that too hard to resist.

As a rule, I don't like to use XML locally. Its suitable for remote calls (web service, http request, etc.), or config files, but that seems to be it for me. Having done it both ways, I think a Java package, such as iText works best.

Thanks for the great question
~~George

[manasa teja]

yes. Itext is realtively very easu to use. I did use it in my previous project with Struts.. We handled as many as 50 PDF reports.
But I think, XSL-FO is for complex reports where as ITEXt is for simple reports.
We did have some performance issues with ITEXT for "big" reports. ( means the PDF will have 500 to 700 pages of data). It was taking plenty of time to produce the PDF to the client, say 8 to 10 minutes. But we had only 3 reports like this, we were able to convince clients.
BUt as Geroge said, ITEXt is relatively easy to understand and use it.
It has very good API and documentation and sample examples are really good!!
May be in this recipe book, they shoould have talked about XSL-FO also for more complex reports and reports with huge data. I am not sure XSL-Fo performance though...

[Lasse Koskela]

Originally posted by manasa teja:
It was taking plenty of time to produce the PDF to the client, say 8 to 10 minutes. ... I am not sure XSL-Fo performance though...

Whether it's iText or XSL-FO, the problem persists -- if your report is huge (hundreds of pages), whatever the transformation implementation is, it needs to do a lot of crunching and possibly swapping parts of the report to disk in order to stay within memory consumption limits etc.

I'd be interested to know if someone has done performance benchmarks between iText and XSL-FO implementations.

[Naina Si]

If the reports are complex and has thousands of pages of data, why can't one use any Reporting tools such as webfocus etc..

I understand that this discussion is not for any Reporting Tools..

But what is the reason one would go for iText or XML-FO when third party tools are available?

One reason i could think of is not everybody recomends using third party tools.

We have all our Java applications on WebSphere 5.1 and we are using 3rd party tools for handling Reports. We tried to generate the PDF report using Java, but it took a lot of developement time as compared to generating report using any Reporting Tool.

I would like to know if there is anything i'm missing here.

[George Franciscus]

A 500-700 PDF would be a pretty big PDF to return to a web client. This is clearly not the norm for a web app. I think iText will give your the performance you want for a reasonably sized report. Lasse is probably quite correct. I would also be interested in a performance comparison between the two, but let's not forget to factor in the cost to create the XML for the transformation.

[manasa teja]

Originally posted by George Franciscus:
A 500-700 PDF would be a pretty big PDF to return to a web client. This is clearly not the norm for a web app. I think iText will give your the performance you want for a reasonably sized report. Lasse is probably quite correct. I would also be interested in a performance comparison between the two, but let's not forget to factor in the cost to create the XML for the transformation.

Yes thats right.. we tried explaining it to our cleints..
but one of teh business clients said " The other report with 100 pages is taking just 40 seconds which is really good, whereas this report with 700 pages is taking 8 minutes, I am not a techie person , but I dont' undertsand the logic here.... it should be taking just 280 seconds. "

We neither..

[friso dejonge]

Hi,
I would like to add something to this quote,

. You need to position your data in XML for the transformation. Therefore, there is the overhead to create XML. That was extra work I would rather not have done. If your data is coming from the Model as XML, then there is an argument to using XSL-FO – but IMO not a strong one.

2. You need to create an XSL style sheet. This means that the developer needs XSL skills. More importantly, the maintenance staff needs XSL skills. Since the developers already know Java, why develop a second skill set?

I' ve been in a project where I had to make sure we were delivering on time and within budget. This means making sure no more hours were actually booked then needed. So my project used iText, and the junior developers could - after reading the documentation start building pdf's. Obviously what we did was create a small framework for common headers, footers etc. We managed.
The learning curve was not too steep. Now I can only imagine what would happen if I gave junior developers the XML-XSL-FO skills to learn. It would never have been on time.

But to be fair the last remark on developers already knowing java, and why develop a second skill set I disagree. Developers nowadays need to know about all sorts of languages and skills (xml - xsl - java/j2ee - ant - junit - sql - etc) But that is up to the developer himself whether he want to invest time in new technologies, or if he wants to get this spoon fed.

regards,
friso

[Jason Menard]

In my opinion there's something to be said with sticking with standards when a "standard" solution exists, particularly as it pertains to corporate decisions. There's ramp-up time either way, and if I'm bringing in a developer off the street I feel there's a better chance that he's been exposed to XSL than a particular not all that common open source API. Of course, I would also expect any developer I bring in off the street to be able to figure out either if needed.

That said, all points raised are certainly valid arguments, but personally, I don't have an issue with XML. In fact, I feel XML data is generally more maintainable and easier to make changes on the fly than to keep the same data embedded in Java classes.

Thanks for the great input.