Instead of having everything in one giant jar (or DLL), we have split iText into several independent parts. You pay only for the parts you use, and your application only needs to load those parts that are actually being used.
- Installation instructions for Java can be found here.
- Installation instructions for .NET can be found here.
Keep in mind you will not be able to simply replace dependencies and expect your code to work. Some migration effort is to be expected.
For the full list of dependencies, check out the POM file for our Java project.
License key upgrade
Several improvements have been made to the license key mechanism. We also added the possibility of automated tracking for volume based licenses. For more information, contact your sales representative.
If you have any difficulties with the license key mechanism, check out the license key FAQ.
Conceptual API changes
iText 5 had grown organically over the years, adding bugfixes and new functionality on top of the architecture. This led to a sometimes messy and counter-intuitive design.
iText 7 is a complete re-design of iText 5, it includes all the functionality of iText 5, but in a way that provides a clear and consistent API. Special attention was given to rendering HTML to PDF (which in iText 5 was possible using XMLWorker). XMLWorker, which was originally intended to convert small snippets of HTML, turned out to be a popular add-on, and more and more features were added.
pdfHTML is the successor to XMLWorker, and similar to the relationship between iText 5 and iText 7, pdfHTML was built to be clear and understandable.
iText7 features a new rendering framework (to accommodate pdfHTML) and several changes in the document model. iText 7 puts more emphasis on the separation of the high-level document model and the low level PDF operators.
With the add-ons we provide, we also extended our international support. PdfCalligraph allows you to easily handle Arabic, Hindi, Tamil and many other complex scripts. This is another conceptual difference. Instead of having everything in one giant jar (or DLL), we have split iText into several independent parts.
You pay only for the parts you use, and your application only needs to load those parts that are actually being used.