44

There were questions on that but not recently and technology must have gone ahead since then.

Requirements:

  • generating pdf documents based on predefined template (I can use either pdf forms or xsl-fo)
  • being able to fill textual data
  • being able to fill graphical data (generated bar codes)
  • being able to alter pdf template in production environment without patching (recompiling)
  • generating pdf file to be saved in the database (as blob) and/or printed
  • open source/free

The options assumed are iText, PDFBox, FOP, anything else? What are recommendations based on the requirements above?

Matt
  • 12,848
  • 2
  • 31
  • 53
topchef
  • 19,091
  • 9
  • 63
  • 102
  • Bar codes are inserted as strings rendered using bar code fonts. I Suppose any PDF library supports them. – Boris Pavlović Jul 08 '11 at 14:30
  • @Boris Pavlović - this is not how barcode4j does it with FOP, is it? http://barcode4j.sourceforge.net/2.1/fop-ext.html – topchef Jul 08 '11 at 14:47
  • 2
    at least have an argument when down voting - I am not in love with my questions - I can address issue(s)... – topchef Jul 08 '11 at 16:36
  • 2
    @topchef: Right, Barcode4J produces images (vector or bitmap). I chose that approach because I find barcode fonts for certain symbologies difficult to handle. You have to know a fair amount about the barcode type and you often have to implement the checksum algorithm yourself. Just this week I was asked why some barcode (made with a font) didn't work. It turned out, they completely omitted the start, end and checksum characters of the Code128 symbol. Barcode4J handles all that for you. Granted, fonts are more light-weight in terms of output size. – Jeremias Märki Jul 08 '11 at 18:22
  • added related question for barcodes and pdf generation: http://stackoverflow.com/q/6627712/59470 – topchef Jul 08 '11 at 20:04

7 Answers7

32
  1. iText; nowadays iText is a commercial library, the latest version is not for free anymore (a fork of an older version remains under MIT license: OpenPDF)
  2. FOP; I worked a lot with FOP. It's fairly resource intensive (Java > XML > XSLT > PDF) and complex PDFs become a nightmare ( may result in XSLTs with 20k+ LoC)
  3. PDFBox; it seems to be the best alternative although I did not work with it in large projects
  4. Did not check Flying Saucer yet

To conclude, I'd give PDFBox a try. Depending on your bar code requirements you may need to inline your barcode (font) into the PDF or distribute the font to your clients - take care of those issues.

debuglevel
  • 434
  • 5
  • 10
home
  • 12,468
  • 5
  • 46
  • 54
  • with respect to barcode: I looked up how barcode4j handles it with FOP - it does it as not a font but an image. I guess I'll need another question on integrating barcodes into pdf... – topchef Jul 08 '11 at 14:44
  • 3
    IText is still open source and free but you are expected to pay if you are using it commercially. Seems very reasonable to me! – mark stephens Jul 08 '11 at 15:19
  • 9
    Yep, it's still OSS. But looking at the licensing terms it's fairly vague: http://itextpdf.com/terms-of-use/index.php Extract: `Buying such a license is mandatory as soon as you develop commercial activities involving the iText software without disclosing the source code of your own applications. These activities include: offering paid services to customers as an ASP, serving PDFs on the fly in a web application, shipping iText with a closed source product.` – home Jul 08 '11 at 17:30
  • 1
    @mark stephens - this is not free if the license is subject to such limitations... not sure if it's called open source in that case. – topchef Jul 08 '11 at 20:01
  • So is GPL open source then. That attaches very clear limitations... – mark stephens Jul 11 '11 at 07:01
  • 1
    Yes, but it's still different from "its commercial software". It's AGPL. AGPL addresses a hole in the GPL with regard to services... people with access to the results need access to the source. – Mark Storer Jul 11 '11 at 22:05
  • 1
    decided on TRYING PDFBox as I already worked with it when using Tika - not final yet... – topchef Jul 15 '11 at 16:33
  • @topchef can you please let us know what have you used at the end and how was your experience with it ? – Sariq Shaikh May 16 '14 at 20:14
  • 1
    @ShaikhMohammedShariq picked PDFBox and had relatively good experience with it but project never went beyond prototype. Main reason for PDFBox was that iText wasn't available for free anymore and FOP was overkill. Clearly, everyone should do their own homework before picking, and quite possible all options evolved since then. – topchef May 17 '14 at 01:44
  • @topchef Thanks for the information. This will surely help to narrow down the existing solutions even if we want to consider them for evaluation. – Sariq Shaikh May 17 '14 at 08:41
  • 1
    It's not very professional to say that iText isn't free software / open source software anymore. For those who don't understand the concept, we've made a 1-minute video that explains it all: https://www.youtube.com/watch?v=QHF3xcWnSD4 – Bruno Lowagie May 05 '15 at 09:39
  • @home itext is offered under AGPL. I don't see anything vague about the terms. The extract you posted just tries to clearify that you will have to disclose the source of your own applications if you choose to use the AGPL version.. – olejorgenb Aug 26 '15 at 10:01
  • @BrunoLowagie: I'm not the expert with regards to legal aspects so my wording might be wrong. Using the library without disclosing the source is my **personal** definition of 'free'. Example: I use iText in a huge project for a large company - do I have to disclose my projects' source code? – home Sep 01 '15 at 16:17
  • @home Without knowing the exact context, I would say: yes, the AGPL means that you have to disclose your project's source code. All the code that touches the free iText (AGPL) needs to be free too. Your **personal** definition about free isn't relevant. The AGPL is what matters. – Bruno Lowagie Sep 01 '15 at 16:27
  • @BrunoLowagie: thanks, but I'd say it's neither my personal definition nor the AGPL - it's all about our customers' requirements. It's not that easy to disclose source code in an enterprise environment. I'm going to update my answer to reflect our discussion... – home Sep 02 '15 at 18:45
  • @home *It's not that easy to disclose source code in an enterprise environment* and that's why enterprises always have the choice to buy a commercial license that releases them from that requirement. How else do you think iText group could win [Deloitte's Fast50](http://itextpdf.com/press/deloitte-fast50-belgium-2015) and all those [other awards](http://itextpdf.com/presshttp)? – Bruno Lowagie Sep 03 '15 at 05:41
  • @home:: "All the code that *touches* ... iText ... needs to be free too" -- define "touches"!! . It is literally impossible to use iText without the O.S. so by that generalized, vague definition, the OS needs to be AGPL also which is absurd.-- In the case where you simply use an unmodified AGPL library, the terms basically convey, that .. ["They do not require you to make available anything else, such as the source code of any software in which you hold the copyright."](http://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant). – Michael M Dec 04 '16 at 19:23
  • 5
    100% Apache PDFBox! The Best. – frekele Apr 05 '17 at 04:55
  • I've been working with PdfBox for couple of months now. It's a nightmare. – Amaneusz Jun 05 '19 at 08:52
6

I've done a project with Flying Saucer http://code.google.com/p/flying-saucer/ which is based on iText. It's free, easy to use, has great support for CSS, and has nice open source.

Brian Hoover
  • 7,861
  • 2
  • 28
  • 41
6

I think your criteria can be met with both iText and Apahce FOp but here you have some additional criteria:

  • licensing: FOP is based on Apache license and therefore "friendly" also for commercial use
  • flexbility: a low level API like iText is more flexible than high level FOP
  • Visual tools: there is one designer for FOP here.
  • Programing Model: iText is based on programming API while FOP requires a XSLFO template and less programming.
  • Proprietary vs standard. Apache FOP is based on a standard and therefore vendor independent, while iText is a proprietaRy API
  • Performace: It is said FOP is more computing intensive. it depends of course of what your target PDF files are. It was a never issue for me using FOP.

I would not use PDFBox, it is good for reading and modifying an existing PDF file but createing a file from scratch using PDFBox can be a lot of work.

user986280
  • 131
  • 3
  • 3
  • "friendly" also for commercial use - you do not have to pay to license it in commercial software but you will not get the support and examples you get with IText. – mark stephens Dec 12 '11 at 08:30
4

I'm a bit biased (committer), but I suggest iText.

generating pdf documents based on predefined template (I can use either pdf forms or xsl-fo)

PDF forms: Check

being able to fill textual data

PDF Forms, check. You can also perform programmatic layout.

being able to fill graphical data (generated bar codes)

Check. Given a known location (which could be "the location of this particular annotation"), iText will draw a barcode for you given a symbology and value. You can deduce a list of supported symbologies from the constants listed here.

For this sort of thing, I use Button fields with an "Icon Only" appearance. The "icon" is some arbitrary PDF drawing instructions, or an image. iText's barcode stuff will create a PdfTemplate you can stuff into the button without too much trouble.

being able to alter pdf template in production environment without patching (recompiling)

If all your layout is baked into the PDF template, and your "barcode goes here" info isn't hard coded into the source, then you're golden.

generating pdf file to be saved in the database (as blob) and/or printed

A PDF is a PDF is a PDF. Heck, with some extra work on your part, you can use iText to build PDF/A files. "A" is for Archive.

open source/free

Open Source: Yes. v2.1.7 was the last version to use the MPL. Since 5.x, all iText releases have been under the AGPL. Yes, iText skipped from 2.1.7 to 5.0, in order to synchronize the version numbering between iText and iTextSharp.

Not exactly "little f" free, but the 2.1.7 version isn't that hard to come by. OTOH, it's orphan-ware, unmaintained. Be an informed consumer.

Mark Storer
  • 15,672
  • 3
  • 42
  • 80
  • thanks for detailed answer! I still have few questions, probably, because of my lack on knowledge of pdf terminology... Do you use terms PDF template and PDF form interchangeably (except for the class `PdfTemplate` that I understand is not related to either)? Does itext offer support for barcodes so I won't need another library to generate them (leaving how feature rich barcode support is outside this question for now)? thanks, again. – topchef Jul 12 '11 at 03:24
2

Another thumbs up for flying-saucer. It works quite well and is easy to use if you're familiar with html and css.

What isn't really documented is how to access iTexts built-in barcode functionality. However this can be easily accomplished. I've put up a short tutorial here: http://andreas.haufler.info/2012/12/generating-barcodes-in-pdfs-with-flying.html

Andreas Haufler
  • 401
  • 4
  • 9
2

It depends how exactly you want to create the PDF as well. FOP works from XML, IText lets you create programmatically from Java.

mark stephens
  • 3,205
  • 16
  • 19
  • I specified in the question that both ways are fine: using forms (itext, pdfbox) or xml->pdf (via xsl-fo). – topchef Jul 08 '11 at 16:33
  • 1
    Not really, if I read your requirements. Going with PDFBox or iText, you have to change Java code and recompile if you change the layout. With an XSLT/CSS-based approach (XSL-FO/HTML), you simply change the stylesheet...which, granted, is also some kind of source code, but it's compiled on-the-fly. – Jeremias Märki Jul 08 '11 at 18:26
  • @Jeremias Märki - Going with PDFBox or iText I plan using pdf form to fill it out and generate new pdf (text and/or image fields). Does it make sense? And, of course, both pdf forms and stylesheets are external to Java code so no recompiling. – topchef Jul 08 '11 at 20:05
-2

nobody is talking about BFO(Big faceless) though it's commercial

Mohammad Faisal
  • 5,783
  • 15
  • 70
  • 117
JunLei
  • 283
  • 3
  • 4