Apache FOP and iText

[Bruce Jin]

Dear Author:

We have been using Apache FOP to generate FDP files. How does iText compare to FOP?

Thanks.

[Bruno Lowagie]

I don't understand why people always want to compare iText with FOP. It are two completely different products. They both produce PDF, but that's it. They aren't interchangeable. There are projects where FOP is the better choice; and there are projects where you're better off with iText.

People using FOP in a project that needs iText, say FOP sucks; people using iText in a projects that demands for FOP, say iText suck. That doesn't make the developers very happy ;-)

FOP is a library that renders XML to PDF. Compared to iText it's not a real PDF library; iText focuses on PDF related features such as encryption, digital signatures, ability to fill in AcroForms,... All this stuff is 'missing' in FOP. Not because FOP isn't a good product, just because this stuff is beyond FOP's purpose. As a matter of fact, iText is mentioned as a tool that can be used for post-processing FOP generated PDFs on the FOP FAQ page.

Unlike with FOP, iText offers a lot of low-level PDF functionality (called 'Direct Content' in iText jargon). It allows you to write PDF syntax using simple statements like moveTo/lineTo.
Why is this important? you might ask. Well, it matters if you're a Swing developer, because this 'Direct Content' is used in a class called PdfGraphics2D. It extends java.awt.Graphics2D translating standard Graphics2D methods (drawString, drawLine) to PDF syntax.
Every Swing component knows how to draw itself to a Graphics2D object, so you can use iText's PdfGraphics2D to draw a Swing component to PDF.
In the book, I use this functionality to convert SVG into PDF with Apache Batik as SVG parser.

There's also a big architectural difference. With FOP an XML file is created BEFORE any PDF is written to the OutputStream. This is OK for small PDF files; but as soon as you have to create PDF documents with 10,000+ pages, you will run into memory problems: why keep the data for these 10,000 pages in memory before writing your first byte of PDF?
Note that this 10,000 page requirement is not unusual in the financial sector (bank statement), the public sector (for instance: my employer, Ghent University), and so forth.

FOP uses more or less an MVC pattern. The model (XML) is separated from the presentation (PDF). If you want to use iText in an MVC design, you should see iText as the engine to generate the PDF (the V-tier in your MVC architecture).
With iText, a page is written to the OutputStream as soon as it's completed. The advantage is obvious (speed and memory); the disadvantage is that you can return to a previous page; but there are ways to work around this.

I could go on for hours on this topic, there are just too many differences to sum up. Just take a look at the projects that use iText. For instance: the major European Airlines: Air France, KLM, TAP,... use iText to generate their online boarding passes. Why not use FOP? Because iText allows you to define the layout in a more accurate way, and because iText is much faster than FOP.

[Bruce Jin]

Thanks for the detailed response!
You said "iText allows you to define the layout in a more accurate way". Is there a visual design tool for this (define the layout)?
Thanks.

[Bruno Lowagie]

Originally posted by Bruce Jin:
You said "iText allows you to define the layout in a more accurate way". Is there a visual design tool for this (define the layout)?
Thanks.

No, iText is a developer's library, not an end user tool. It doesn't have a visual tool. For a Swing developer, it's quite easy to build one, as he can render his canvas to PDF file using java.awt.Graphics2D.
But the way I see it, that wouldn't provide more accuracy. On the contrary ;-)
When I say iText allows you to define the layout in a more accurate way, is that you don't have to depend on design decisions of the library for instance when it comes to pagination. With class ColumnText you have a means to write code that decides when a new page should be triggered.
With more accuracy I also mean you can control the PDF at the lowest level.
For example: iText was used in a project for the Australian Army to draw detailed maps (based on ESRI data). These PDFs had 'optional content' layers. These are layers than can be turned on and off.
In the book, there's an example of a map of a city. First you see a raster image, but when you zoom in, the document switches to a vector image. By turning optional content layers on/off, you can display street names in different languages; you can also make icons (in)visible. These icons indicate where to find restaurants, hotels, movie theatres,... in the city.
See http://itext.ugent.be/itext-in-action/examples/chapter12/results/interactive_city.pdf

[Bruno Lowagie]

Note that this interactive_city.pdf was generated based on an SVG file that was made manually. If you feed it with an SVG that with a better quality, you'll get a better quality PDF.
On another note: do you know about Folio? It's an FOP port to Java5: http://defoe.sourceforge.net/folio/
I don't know its current status, but I know it combines the architecture of FOP with the power of iText ( see http://defoe.cvs.sourceforge.net/defoe/Folio/lib/ ). Comparing FOP with iText is like comparing a Jaguar with a BMW engine. You can't drive to work with only a BMW engine. You can drive to work with an engineless car. But if you combine both, you can certainly get somewhere ;-)

[Bruce Jin]

Thanks Bruno.

Just read sample chapter 1 and 3. Great!
We will look into iText.