Bump itext7 from 8.0.5 to 9.4.0 #16
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updated itext7 from 8.0.5 to 9.4.0.
Release notes
Sourced from itext7's releases.
9.4.0
For our fourth and final iText Core release of 2025 we’re introducing advanced page resizing functionality for more effective merging and manipulation of PDF documents with varying page sizes.
We’ve also been working on extending the new EU eIDAS Trusted Lists feature to support validation against specific signature profiles.
In addition, we’ve enhanced our flex layout support within the layout module for use with the pdfHTML add-on.
Advanced Page Resizing
This release introduces advanced page resizing functionality, allowing users to merge and manipulate PDF documents with varying page sizes more effectively. This was based on a customer request who was using similar functionality in iText 5. However, the way iText 5 did this was relatively unsophisticated, and ran into problems with tagged documents and different content types.
This new implementation addresses scenarios such as scaling content between different page formats (A0, A1, US Letter, etc.), maintaining aspect ratios, and handling annotations, patterns, gradients, and form fields during resizing. The result is a more flexible and reliable toolkit for document assembly and transformation, ensuring that content integrity and layout are preserved across diverse PDF workflows.
Signature Profiles Support
This focuses on enhancing digital signature capabilities in iText Core by introducing support for signature profiles. This feature enables an easier way to ensure that digital signing and validation processes meet the regulatory and compliance requirements for specific regions. As a demonstration, we’ve updated the
LotlSimpleSignatureValidationsample (Java/.NET) on GitHub to show off the newQualifiedValidatorclass. This determines if a given certificate/signature meets the regulatory standards to be “qualified”, which is vital for high-trust electronic transactions.We’ve also made a change to LOTL validation reports to eliminate multiple successful validation messages during the process, along with some general improvements to LOTL caching and validation.
Extending Flex Layout Support
This release significantly improves the flex layout support in the core Layout module. Since this primarily affects pdfHTML, you’ll find more details in the release notes for pdfHTML 6.3.0.
Pull Requests
We’d like to thank IBaltaga for their suggested NotSupportedException if AreaBreak is inside a flex container fix for .NET. After investigating in more detail we decided to implement the fix in a different way, however, an exception will no longer be thrown for AreaBreaks inside flex containers.
Bug Fixes and Miscellaneous
PDF image and color depth handling has been enhanced when extracting images There are also accessibility and structure improvements in generated/tagged documents, and error messaging and recovery for malformed or edge-case PDFs is improved.
For .NET, we’ve implemented a wrapper for Asn1OutputStream which became available in version 1.0.2 of BC FIPS .NET. This improves cryptographic compatibility for FIPS workflows.
Other Stuff
As always, you can see the Changelog below to see the full rundown on what’s new in Core, and details of other improvements and bug fixes for this release.
Java
.NET
NOTE: If you want to create ZUGFeRD/Factur-X-e-invoices with iText Core, we have both Java and .NET code samples available targeting the current ZUGFeRD/Factur-X specification. They demonstrate how to embed the XML invoice data and add the metadata required for conformance.
... (truncated)
9.3.0
For this Q3 release of iText Core we’ve further enhanced iText’s digital signature validation by adding support for the official EU eIDAS Trusted Lists. Not only that, there’s also improvements to thread safeness and further work on the .NET MAUI support we introduced in version 9.2.0.
EU Trusted Lists in Validation
Furthering our efforts to make developers' lives easier when dealing with PDF digital signatures, we’re pleased to announce that iText now supports retrieval, validation, and usage of the EU’s List of Trusted Lists (LOTL). This greatly simplifies the process of establishing a chain of trust for electronic signatures, and helps ensure that signatures validated with iText meet stringent European standards for trust and authenticity..
For those unaware, the LOTL is a central, signed XML file containing links to trusted lists from EU and EEA Member States. These Member State lists identify both trust service providers and the trust services they offer; e.g. digital signatures and seals. The LOTL is an official resource which aids achieving compliance with EU eIDAS regulations. Previously, you would need to manually provide the trusted certificates to use for validation with iText; which is still possible, but is less convenient. Now, iText will retrieve, parse, and validate the LOTL to provide the root trusted certificates for you.
For security reasons, rather than expect iText to repeatedly retrieve the trusted certificates to validate the LOTL from the Internet, we instead provide a specialized repository which has the required certificates pre-downloaded. This can be found on GitHub, or alternatively on Maven and NuGet.
You can find full details on this implementation and its usage linked in the release notes on the iText Knowledge Base.
Thread Safety Improvements
Internal updates have improved thread safety across key components, making iText Core more robust in multithreaded environments. This is especially beneficial for developers building scalable, concurrent applications.
Faster XMP Metadata Parsing on .NET
.NET performance improvements include replacing
forloops withforeachloops. TheiText.Kernel.XMP.Impl.ParseRdfclass is heavily used in XML-based metadata parsing, and the change significantly speeds up processing of large XMP collections.Improved .NET MAUI Compatibility
Building on the support for Native AOT compilation in the previous release, iText Core now offers better compatibility with .NET MAUI, supporting cross-platform mobile and desktop development and integration into modern .NET applications.
Pull Requests
We’d like to thank SangeethaDivya for their contribution to remove duplicate constants on .NET, which we used as a basis for a Java reimplementation and ported it to .NET. Thanks also to craffael who fixed a typo in the PDFA-1 checking code which led to documents with no device-dependent color spaces failing the checks.
Bug Fixes and Miscellaneous
A bug in PDF 2.0 structure destinations has been fixed, improving how tagged content is linked and navigated when converting from HTML. This is now more in line with the PDF 2.0 and PDF/UA-2 specifications and is particularly useful for accessibility and structured document workflows.
We’ve also fixed an issue related to color depth support in PDF image data streams, which would result in an
com.itextpdf.io.exceptions.IOException: The color depth 1 is not supported.error.We’ve also resolved a StackOverflowException resulting from invalid PDFs with cyclic references in the trailer dictionary, improving robustness and error handling.
Other Stuff
As always, you can see the Changelog below to see the full rundown on what’s new in Core, and details of other improvements and bug fixes for this release.
Java
.NET
... (truncated)
9.2.0
Following the 25th anniversary release last time, you might think there wouldn’t be much to expect from iText Core 9.2.0. But hold onto your hats, because we have some very nice stuff to talk about! This includes support for .NET MAUI AOT compilation, automated validation for PDF/UA-2 documents, and some other goodies including…iText for Python???
.NET MAUI AOT Compilation
The standout feature of this iText Core release is its support for Native Ahead-of-Time (AOT) compilation in .NET MAUI development. After introducing GraalVM Native Image compilation on the Java side last year, we’re thrilled to bring similar perks to our .NET developer community. Since the addition of the NativeAOT runtime for iOS and macOS development in .NET 9’s Multi-platform App UI (MAUI), we began implementing support as it could bring significant benefits for iText development.
In addition to the usual benefits of optimized native executables—like smaller file sizes, faster startup times, and reduced memory usage—Ahead-of-Time (AOT) compilation really shines when it comes to iOS development. This is mainly because there are some pretty strict rules around traditional Just-In-Time (JIT) compilation for apps that are headed for the App Store. So, leveraging MAUI’s AOT runtime could really be a game changer.
Automated PDF/UA-2 Validation
Automated checks for PDF/UA-1 creation were introduced with iText Core 8.0.4. This release extends this feature to include the new PDF/UA-2 standard published last year.
The earlier checks were based on the PDF Association’s Matterhorn Protocol PDF/UA conformance testing model. For the PDF/UA-2 checks, we draw from the profile used by the industry-standard validation tool, veraPDF. That said, the way we’ve implemented the system of checkpoints and handle failure conditions is broadly the same. So, rest assured, iText Core will help you create PDFs that meet the new standard for universal accessibility.
While at present we’re not aware of any legislation mandating the switch to PDF/UA-2 from the current PDF/UA-1 standard, there are some pretty compelling reasons to consider adopting the latest version, particularly when it comes to handling PDF 2.0 documents. PDF/UA-2 brings improved support for modern Unicode to the table, and rolls out new document structure elements like Title, DocumentFragment, Aside, FENote, and Artifact which take advantage of enhancements in the PDF 2.0 specification.
In addition, we have refactored the conformance-checking mechanism by introducing the new PdfConformance abstraction to support multiple standards (e.g. PDF/A, PDF/UA), with PdfAConformance and PdfUAConformance now existing as enums, enabling modular, extensible validation.
Pull Requests
We’d like to thank Aviad Pineles for their PR to improve CSS style sheet logic for pdfHTML. While we eventually went with a different implementation of this fix, we’re very grateful for the inspiration!
Bug Fixes and Miscellaneous
In line with our efforts on the PDF/UA-2 checks and the upgraded API for converting HTML to PDF/UA, we also have some enhancements and fixes for general PDF 2.0 conformance. One of the standout updates is a dedicated checker that evaluates tag structure by examining the parent-child tag relationships as outlined in the PDF 2.0 specification. We’ve also addressed a number of issues related to PDF 2.0 tag conversion and structure repair operations, making sure everything operates seamlessly.
We would also like to highlight an additional change: in response to a bug report on StackOverflow, we identified and resolved a line wrap issue affecting non-wrapping italic and bold simulated text within table columns. This problem could lead to incorrect page breaks when the content width exceeded the column limits. To fix it, we’ve adjusted the table renderer logic to handle cases where text formatted in such ways exceeds the layout box width.
Other Stuff
Those of you who were intrigued by the reference to Python at the beginning will be interested in a new article in our Technical Tales section of the Knowledge Base. Vlad Lipskiy from our Research Team has been very busy over the past few weeks exploring how Python.NET can enable direct usage of iText from Python. In addition to porting a wealth of code samples, he’s also written a superb article which takes a deep-dive into how it all works. Make sure to check it out!
Another great article is by Guust Ysebie from the iText SDK development team. If you caught the iText Core 9.1.0 release, you might remember how we managed to massively speed up table rendering, particularly in the case of tagged tables. If you wondered how this was possible, Guust has written up the whole story from beginning to end. It’s a very entertaining and enlightening read, so if optimization is your bag you’ll find a lot to enjoy.
NOTE: If you use iText for digital signing, you may be interested in the Digital Signatures Hub which contains a ton of useful resources and examples. In particular, we have a new chapter to our Digital Signing with iText series. In Part V, we take you through the steps of signing PDFs with Java via a remote signing service offering CSC API access.
Don’t forget that in addition to the resources on our Knowledge Base, on our GitHub you can find a ton of useful up-to-date samples in the following repos:
As always, you can see the Changelog below to see the full rundown on what’s new in Core, and details of other improvements and bug fixes for this release.
Java
.NET
... (truncated)
9.1.0
To celebrate both iText’s 25th anniversary and Valentine’s Day, we bring you iText Core version 9.1. There’s a lot of to love about this release, with a huge performance increase in table creation, massively extended SVG support, and further Digital Signing goodies.
Extended SVG Support
Many additions and enhancements have been made to our in-house implementation since it was introduced, with coverage of the specification steadily increasing to meet customer needs. This release sees our biggest leap yet with over 40 tickets being closed – full marks to our incredible dev team!
Newly added are support for text clipping paths, 'marker-mid' properties, text decoration, and passing markers from elements to children. We’ve improved general font handling, while some other improvements to draw attention to are in the support for relative size attributes, text positioning, 'direction' properties, stroke opacity, and dash patterns.
There's also improved support for CSS-specific SVG, which you can find more details on in the pdfHTML release notes. However, we'll call out the improved support for different CSS origins in SVG and referencing external resources with the
@importurl()rule.To top it off we’ve significantly improved the SVG module’s usage of the advanced typography features enabled by the pdfCalligraph add-on. See the example PDF on our Knowledge Base for a demonstration!
Increased Table Performance
With iText Core 9.1 the table rendering code has been highly-optimized, particularly when it comes to tagged tables. This is especially noticable for tables with many rows, or when tagging tables. See more details
Digital Signatures
We’re continually working on iText’s digital signing and validation capabilities to provide a unique breadth of support in the market. MAC integrity protection support is extended to support two-step signing. There’s also new code examples for signing with the Cloud Signing Consortium (CSC) API, which we recently wrote about in Part V of our Digital Signing with iText series. You can find these in the GitHub samples repositories linked below.
Alongside that, we’ve made some general improvements (if you know, you know) to signing and validation. In particular, the workaround for certificates where the
pathLengthparameter is set to 0 for thebasicConstraintsextension is no longer required.PDF/UA-2
Our PDF/UA-2 implementation is improved, specifically, when using the Annot tag for content elements in PDF 2.0 documents.Don’t tell anyone, but our team is preparing further PDF/UA-2 goodies for our next release.
Pull Requests
For this release, we’d like to thank Stefan Bechtold for submitting a PR adding support for styling tables with nth-last pseudo class selectors. Thanks also to Artyom Skrobov for squashing a bug when decoding an empty PdfString, and finally Zuzu-Typ for fixes to the kernel PDF encryption constants documentation.
Bug Fixes and Miscellaneous
There’s an update for merge handling when remote and embedded go-to actions are present, and we resolved a customer issue related to decoding Xref streams with missing bytes.
Many bugs have been resolved for SVG rendering and CSS layout. In addition, general bugfixes have been made to font and text handling, form fields, signing and validation, and more.
Other Stuff
If you use iText for digital signing, you may be interested in the Digital Signatures Hub which contains a ton of useful resources and examples. In particular, we have a new chapter to our Digital Signing with iText series. In Part V, we take you through the steps of signing PDFs with Java via a remote signing service offering CSC API access.
Don’t forget that in addition to the resources on our Knowledge Base, on our GitHub you can find a ton of useful up-to-date samples in the following repos:
Java
... (truncated)
9.0.0
For this Q4 release, we’re pleased to announce a new major version of iText. iText Core version 9.0 introduces significant new features, support for new specifications, and revised APIs to delight developers.
We’ve added support for the ISO/TS 320003 and 320004 standards, enabling even more secure PDF documents. Also on the list is the finalized digital signature validation module, along with a new API to easily get layers used in a page, and improved PDF/UA signing.
New ISO Standards Support
First and foremost, iText Core version 9.0 incorporates support for the very latest ISO PDF document security standards. ISO/TS 32003 adds AES-GCM encryption to the PDF 2.0 specification, allowing documents to be protected with high-performance, yet extremely secure encryption.
ISO/TS 32004 introduces an integrity protection mechanism for encrypted PDFs, using a Message Authentication Code (MAC) to ensure authenticity. To fully understand what this means for securing PDF documents, we highly recommend reading two great articles on the PDF Association site: ISO 32004: an overview and the follow-up MACs vs. signatures in PDF which go into detail on this subject.
Digital Signature Validation Module
On the subject of PDF digital signatures, we’re also proud to present the finalized version of our dedicated validation module. This forms an integral piece of iText’s enhanced digital signing capabilities introduced with iText 8.
The aim is to provide simpler, more extensive API methods to not just sign PDF documents, but also validate the digital signatures within them – whether iText created them or not. Since you can validate multiple document revisions as well as certificate chains, iText can now be your Swiss Army knife for digital signatures, as well as PDF creation and manipulation.
This release enables you to only validate a single signature in a document, as opposed to all signatures. In addition, the signature validator will now work for encrypted documents.
API Improvements
There are also major refinements to iText’s API. These include streamlining PDF/A and PDF/UA creation and conformance to simplify the process. We’ve also developed a new API to identify the layers used in a page. This will help to find which Optional Content Groups (OCGs) belong to which page in a document.
Signing of PDF/UA documents has been improved. When creating a signature form field iText will now take into account if an alternative description is set in the accessibility properties of the signature appearance. Additionally, if you forget to set a font for the signature appearance this will now result in a conformance exception, rather than a property error.
Further improvements have been made to the rebuilding of invalid cross-reference (xref) tables in corrupt documents. When iText encounters and resolves such errors in non-strict mode, specific information on the cause will now be provided.
Adding to the recent addition of RSASSA-PSS encryption support for .NET, this release now allows it to be supported in FIPS mode.
Along with that is improved font selection and general handling, performance enhancements, and much more. iText has a reputation amongst Java and .NET developers for its speed and ease of use, and we’re ensuring that remains the case in the future.
Make sure to check out the Breaking Changes if you’re migrating from a previous version of iText.
Pull Requests
Once again, we’d like to thank Matthias Valvekens for another pull request submission. This relates to Unicode, and adds support for platform 0 encoding 3 in the Truetype and OpenType character map table. This is used in some fonts shipped with macOS, among other places.
Bug Fixes and Miscellaneous
For content extraction, we fixed a bug in the
RegexBasedLocationExtractionStrategyAPI (Java/.NET) . It now produces better results by default when processing multiple pages.We fixed an edge-case bug in Certificate Revocation List validation. When a CRL response existed, but its issuer was neither trusted, nor self-signed, it could result in a stack overflow error.
In addition, a fix was made to SVG rendering to honor
dyattributes in parent text attributes.Other Stuff
... (truncated)
Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)