Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

PDF Generation Library for Java [closed]

I know this has been asked before, but I'm still undecided on which PDF generation framework to use for my current project.

My requirements

  • on-the-fly generation of PDF documents (mainly order forms, invoices)
  • Java based
  • easy to layout
  • should be open source
  • easy to change layout

A lot of people seem to use iText, but I have some concerns (apart from the changed licence) regarding separation of concerns: In an HTML context there's good MVC support, where I usually stick to Spring MVC and FreeMarker to separate logic and layout. I'm a little bit worried that with iText you end up mixing code and layout a lot.

I am aware, that Apache FOP could be a solution here, but then again I find XSLT tedious to work with and I read that FOP can be slow when it comes to huge throuput of many documents?

I also considered JasperReports, but from my understanding this is more suited for reports containing tabular datasets rather than single documents such as invoices which require a lot of layout formatting?

Any thoughts on this?

like image 534
Stefan Haberl Avatar asked Oct 21 '10 09:10

Stefan Haberl


People also ask

Which is better iText or PDFBox?

One major difference is that PDFBox always processes text glyph by glyph while iText normally processes it chunk (i.e. single string parameter of text drawing operation) by chunk; that reduces the required resources in iText quite a lot.

Is PDFBox open source?

The Apache PDFBox® library is an open source Java tool for working with PDF documents. This project allows creation of new PDF documents, manipulation of existing documents and the ability to extract content from documents.

Is Apache PDFBox free?

PDFbox is that PDFbox is the free version.


2 Answers

Give JasperReports a try. Use iReport to create the .jrxml files. JapserReports can handle complex layouts. For those parts of the report based on different queries have a look at using subreports embedded into the main report.

Just like @Adrian Smith's solution this approach will separate the report layout editing from the data sourcing.

like image 55
Janek Bogucki Avatar answered Sep 22 '22 12:09

Janek Bogucki


I have implemented a good solution where my software creates a format-independent "pure" XML file, then I give my boss the XSD and he puts it into Altova StyleVision where he can WYSIWYG design reports based on data he plucks out from the XSD. That software produces an XSLT. So my program:

  • Produces the format-independent "pure" XML
  • Transforms it with the XSLT, the output of which is XML-FO
  • Use Apache FOP to convert the XML-FO into PDF

This is a really great solution, means no more do I (as a programmer) have to change my code each time my boss wants to change a color in the report, my job is simply to produce "pure" XML.

Update: I should also point out that I give my boss access to our SVN repository with Tortoise SVN which is sufficiently easy to use that he can use it without error. So he can check the XSLT files straight into SVN and run the build/deploy without even having to interrupt me from my work. Obviously that workflow only works with people who are sufficiently exact that they don't make mistakes etc., but it works out well for us in that case.

like image 36
Adrian Smith Avatar answered Sep 21 '22 12:09

Adrian Smith