As you have probably noticed by now, we have recently released iText 7, a new major version of our flagship library, which is not backwards compatible to iText 5. This technical blog post will focus a bit more on the reasons why we chose to rewrite iText 7 from scratch and will also detail our roadmap for the near future.
While we were always pretty happy with the capabilities of iText as they stood, there were a number of design choices that limited our wiggling room for further development. Over the years, a number of changes were introduced that used and transformed the existing framework in unintended, or even borderline improper ways. This was not per se a bad thing for the existing functionalities, but it made further extensibility - and, importantly, future-proofing for PDF 2.0 - much more difficult. Furthermore, some APIs were entirely public, which hampered our potential to reimplement functionality.
As a result of all this, we decided to rewrite iText from scratch in December 2013, thus breaking backward compatibility. Building from the ground up allowed us to make performance improvements that were impossible with the existing code, to make iText much more extensible and configurable from client code, and to get rid of some of the cruft that a project inevitably accumulates. The main improvements from a user's viewpoint are:
iText 7 is modular, whereas the core library for iText 5 was one big JAR/DLL. You may need only a few of the modules for your use case, so you can reduce the total size of your compiled application. Add-ons are available for specific functionalities, but they don't encumber users that don't need them.
uniformity in the PDF rendering engine. In iText 5, there were several rendering APIs that had a lot of functional overlap but also showed (sometimes subtle) differences in behavior.
the Renderer framework, which lets you plug custom layout code into the standard library, thus reducing the need for the kind of feature requests that led to iText 5's mild case of featuritis.
Things that stay the same
While designing the code, we of course depended on our experience with our older versions. Since iText 5 already does a lot of things well, we took over some of its behavior and characteristics.
The licensing model is unchanged: iText 7 is still released as FOSS software under the AGPL software license, with commercial options available to users that do not wish to adhere to it.
PDF parsing and text extraction was ported with only a few object name changes.
The signing module is functionally equivalent to, and virtually unchanged from the iText 5 implementation.
The PDF/A functionality is as easy to use as in iText 5.
The layout module, with its HTML-like objects like Paragraph, List, etc, corresponds very closely to the high-level API of iText 5. Some classes have been renamed, but everything is very similar and transition should be easy for basic use cases. For more advanced use cases, you'll need to look into the Renderer framework.
We did an early release of iText 7 for Java on May 1 to support our presence at the Great Indian Developer Summit and to underscore our dedication to supporting any script system in PDF. On June 17, the iText 7 port for.NET came out. From then on, we've started focusing on finishing our ongoing efforts to write documentation and tutorials to accommodate users and to document our own, in-house experiences with the new code base. We'll also write a successor to iText 5's successful XMLWorker add-on, to support users that prefer to design their PDF reports with HTML and/or custom XML syntax.
iText 7 is built upon the Java SE 7 platform. Earlier versions have been EOL for multiple years and are not commonly used for new projects. Even though Java 7 itself is also (more recently) EOL, it is still very commonly used in the Java community. Another reason why we couldn't really go lower is that we use the enum java.lang.Character.UnicodeScript, which is only available from Java 7 onwards. Similarly, the .NET version of iText 7 targets the .NET Framework 4.0 as a reasonable base line for the future. We are also planning to support .NET Core and UWP in the near future alongside the .NET Framework.