Bump itext7 from 8.0.3 to 9.6.0#49
Merged
stesee merged 2 commits intodependabot/nuget/LockPDFy/itext7.bouncy-castle-adapter-9.6.0from Apr 24, 2026
Merged
Conversation
--- updated-dependencies: - dependency-name: itext7 dependency-version: 9.6.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
.NET
dependabot
Bot
added
dependencies
stesee
approved these changes
Apr 24, 2026
stesee
changed the base branch from
main
to
dependabot/nuget/LockPDFy/itext7.bouncy-castle-adapter-9.6.0
…9.6.0' into dependabot/nuget/LockPDFy/itext7-9.6.0
stesee
merged commit 439b85b
into
dependabot/nuget/LockPDFy/itext7.bouncy-castle-adapter-9.6.0
2 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
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.3 to 9.6.0.
Release notes
Sourced from itext7's releases.
9.6.0
Our second iText Core release of 2026 will please those with a focus on creating accessible and reusable content in PDF. We’ve introduced the ability for iText to perform automatic color contrast checks during creation of PDF/UA documents, which will aid when ensuring generated documents meet many countries' accessibility regulations.
We’ve also added high-level functionality to make creation of Well Tagged PDF documents easier, by letting iText’s comprehensive conformance checking architecture handle all the tricky stuff behind the scenes. You can also target the reuse and accessibility conformance levels defined in the WTPDF specification, depending on your requirements. The accessibility level directly aligns with PDF/UA-2, while reuse is optimized for content extraction, reflow, and machine-driven transformation.
In addition, we’ve extended trusted list validation to include non‑EU countries, along with general improvements to digital signature validation and certificate retrieval.
PDF/UA Color Contrast Checks
For documents to comply with the PDF/UA specifications, you must ensure that foreground and background colors meet the necessary WCAG standards for accessibility. If there is not enough contrast then not only will documents fail in accessibility checkers, text and graphical content will be difficult to read.
Color contrast checking is something that still requires human intervention in most cases, however, iText Core can now warn you if such issues are detected during document creation. It should be noted that this is not a comprehensive check and cannot substitute for an actual “human in the loop”. However, it will help to identify and avoid obvious issues at an early stage.
This functionality is similar to that provided by the WebAIM Contrast Checker, where you can select different values for the foreground and background colors. For WCAG 2.1 level AA which is commonly specified in accessibility regulations, normal text must have a contrast ratio of at least 4.5:1, and 3:1 for large text, graphics, and user interface components (such as form input borders).
We have also improved iText’s layer handling to better accommodate these tests. Previously, reopening a document and accessing layers via
PdfPage.getLayers()always returned layers in the “on” state regardless of their persisted visibility. Now, layer properties are correctly persisted after saving and reopening.Easier WTPDF Creation
The PDF Association’s Well-Tagged PDF (WTPDF) standard specifies requirements for creating PDF 2.0 documents geared towards reuse and accessibility. While both use cases have a large overlap in requirements, some are critical for reuse while others are only required for accessibility. Therefore the standard has conformance levels that clearly identify the requirements for each.
The reuse level is intended for PDF content to be more easily repurposed, extracted, or reflowed, including use cases such as PDF to HTML conversion and enabling responsive layouts on mobile devices. The accessibility level uses the same structural tagging model, but focuses more on ensuring people using assistive technologies can navigate and understand the document.
WTPDF document creation with iText Core was introduced along with the support for PDF/A-4 and PDF/UA-2, which are both based on the PDF 2.0 specification. However, we’ve since added a comprehensive validation architecture with specialized document classes and validation checkers to enforce compliance when targeting specific standards.
To bring WTPDF into line there is now a dedicated
WellTaggedPdfDocumentsubclass ofPdfDocument, to join the existingPdfADocumentandPdfUADocumentclasses. In addition, thePdfConformanceclass now includes the accessibility and reuse conformance levels.All these changes mean creating WTPDF documents with iText is just as easy as PDF/A and PDF/UA, with no need to worry about remembering which requirements apply to the conformance level you’re targeting. You can now simply use
WellTaggedPdfDocumentto create a WTPDF document just like you would usePdfUADocumentto create PDF/UA, and let iText do the hard work for you.Non-EU Trusted List Validation
In iText Core 9.3.0 we introduced the List of Trusted Lists (LOTL) system, which lets iText fetch, validate, and cache European lists for eIDAS compliance. To better accommodate other countries which also issue and maintain trusted lists of their own, we’ve extended the feature to include a broad non‑EU processing implementation.
This was achieved by adding a convenient “single file trust list” alternative implementation path, useful for countries where you have a single XML trust list rather than an EU-style LOTL + pointers ecosystem. The existing LOTL services have been refactored to support this, and the existing Ukraine and Moldova trusted lists samples have been updated to use this new implementation.
You can refer to the Java and .NET sample repositories to find the LOTL validation examples updated for this release.
Improved Digital Signature Validation and Certificate Retrieval
For digital signature validation we’ve introduced a single, configurable mechanism to control all online data retrieval (such as CRL, OCSP, issuing certificates, and LOTL), making it easier to enforce network policies and increase reliability in restricted environments.
Certificate chain building and validation have been updated to better handle complex PKI setups. Chain construction now collects all reachable certificates, including multiple CA candidates and cross-signed certificates, without enforcing constraints during the building phase.
Validation then applies RFC 5280–compliant checks over the resulting paths, with a particular focus on correctly enforcing inherited name constraints across the entire certificate chain. This separation of chain discovery and validation improves robustness and correctness when working with real‑world certificate hierarchies.
Pull Requests
For this release we’d like to thank schallb for their contribution to improve
LocationTextExtractionStrategy(Java/.NET) by adding support for custom element and newline separators.As the author describes, they needed a way to better distinguish between spaces and newlines that are part of the extracted text, and the separators inserted by iText when it decides a word boundary or new line between chunks exists. Thanks to this change, the separators inserted in the formatted extracted text can be overridden.
... (truncated)
9.5.0
In this first iText Core release of 2026 we’re focusing on upcoming additions to the PDF specification; specifically adding support for Brotli-compressed PDF streams, and post-quantum-safe algorithms for digital signing.
The validation of PAdES signature profiles has been improved to detect Document Security Store changes between revisions.
In addition, there are various improvements and fixes across the core modules. See below for more details.
Support for Brotli Compressed PDF Streams
The Flate/Deflate compression method was first introduced in version 1.2 of the PDF specification back in 1996. Based on zlib, it has served well though is rather long in the tooth these days. With that in mind, the PDF Association plans to add support for the modern Brotli compression standard to the PDF specification in the near future. As befits our position in the industry, we're introducing Brotli support to iText now rather than later.
In this release we’ve added proof‑of‑concept support for reading and writing PDFs that use Brotli compression, including a new filter handler and corresponding high‑level API hooks.
For now at least, you should consider this feature experimental, since current support for Brotli-compressed PDFs in other software is scarce. Even after it becomes part of the official specification it will take some time for the majority of PDF viewers and browsers to support such documents. As always with new standards and technology, however, it's important for iText along with other major PDF vendors to adopt and popularize them as soon as possible.
For those brave souls who wish to proceed, the new brotli-compressor module is only available from our artifactory, for now. See the README for more details on its usage and configuration.
Post-Quantum-Safe Digital Signature Algorithm Support
Once again, this is one for the future; albeit a rather more uncertain one. Quantum computers are beginning to step outside of the purely theoretical world, and with them comes the dangers of Q-Day. That is, the day when a quantum computer could conceivably instantly render existing means of encryption obsolete.
Fortunately, some extremely clever boffins have been aware of the dangers for some time, and a variety of encryption algorithms has been developed to counter quantum-based attacks. Thanks to the venerable Bouncy Castle cryptographic modules used by iText, we have implemented POC support for the Post-Quantum algorithms supported by Bouncy Castle.
Again, official support in the PDF specification will be coming soon and so it's time for us to implement support in iText. However, it should be noted that these are not yet supported in FIPS mode, as the official PQC-safe algorithms for FIPS are still to be defined. Once PQC-safe FIPS mode is possible, you can be sure iText will be at the forefront of PDF implementations.
PAdES Signature Profiles
We've made further headway into making digital signatures easier with preset PAdES signature profiles. The PAdES profile validation is improved and can detect when the Document Security Store (DSS) changes between revisions. It will emit a TimestampsAfterDSSEvent when appropriate, improving timestamp validation accuracy.
Also in this release you'll find new samples for the Ukraine and Moldova trusted lists which are available from the European Commission's eIDAS Dashboard site.
Pull Requests
For this release we want to thank dajoropo for their contribution to improve error handling when an attempt to create a PDF from a TIFF image fails. Now, iText Core will include the original exception to assist in diagnosing why the error occurred.
Bug Fixes and Miscellaneous
We have introduced a common, cross‑platform JSON AST and converters to serialize/deserialize between Java/C# objects and a unified JSON representation, improving maintainability and GraalVM/AOT support.
Support for East Asian (Japanese) line‑breaking rules in the layout module was added to avoid orphan punctuation at the beginning of lines, improving typography for Japanese text.
We also investigated and resolved an issue with form filling and flattening introduced after version 9.0.0, after a customer reported a regression in performance.
A bug in calculating the maximum number of XRef elements was fixed, avoiding potential overflow issues in large documents.
We fixed an issue preventing OCG layers from being added, modified, or removed in append mode was fixed, including when no prior OCG layers existed.
We also fixed the handling of unencrypted metadata in encrypted documents by aligning decryption logic with encryption dictionary flags (AES‑256 vs AES‑GCM behavior), and clarified how metadata is treated on creation.
A bug when validating a PDF signature was resolved, where iText did not use OCSP/CRL responses that were added to the document’s DSS in a non-timestamped revision.
... (truncated)
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)
8.0.5
For our Q3 2024 release of your favorite open-source PDF library we’ve continued our work on refactoring the sign module, with further improvements to digital signatures thanks to a dedicated validation API.
The other big news is the addition of the CSS Grid Layout Module. Similar to the already supported Flexible Box Layout, it’s a powerful tool for controlling the sizing and positioning of boxes and their contents. However, while Flexbox is one-dimensional, Grid Layout is optimized for layouts where content alignment is desired in two dimensions.
We’ve also improved the handling of corrupted PDF documents, with more descriptive exception messages when iText encounters files with unreadable object streams, and other general improvements.
Built-in Signature Validation API
Eagle-eyed devs will have noticed we introduced a bunch of dedicated classes for the validation of digital signatures. We’ve been transferring and refactoring the existing validation logic into the
validation.v1package and adding additional classes for new functionality. The package will be renamed with the next major iText release, but the validation API itself is already completely functional, and available now for you to start using it.In this release, we’ve added the
SignatureValidatorclass, as well as theValidationReportclass. You can find information on their usage in the examples for this release on the iText Knowledge Base, or check out the Java and .NET signature validation examples which have been updated with this release.In addition, the
OCSPVerifierclass has been deprecated as of this release, and you should useOCSPValidatorinstead. Check out the API links above to see all the validation-related goodies in this release!Support multiple CRL distribution points per certificate
Previously
CrlClientOnlinewas only capable of retrieving a single url per certificate. This was incorrect since the CRL Distribution Points certificate extension can specify multiple distribution points and thus multiple urls. Now an instance can be created using a certificate chain to retrieve a CRL list of multiple urls to be further used as revocation data.Document Revision Comparisons
Following on from the support for parsing document revisions in the previous release, we’ve introduced mechanisms to validate document revisions at the
DocumentRevisionsValidatorlevel, based on the DocMDP and FieldMDP standards. As explained in the EU Digital Signature Service (DSS) documentation, DocMDP “defines access and modification permissions granted for a PDF document using a certification signature”, while FieldMDP “defines permission issued for modifications within form fields (including signature fields).”Grid Layout Support
While Grid Layout is mainly a feature for use with our pdfHTML add-on, the main Grid layout logic is located in the iText Core layout module. Because pdfHTML makes heavy use of the layout module in order to render HTML elements, it’s technically possible for layout module users to use this new feature directly for greater fine-tuning of documents.
However, since we imagine most people will be using pdfHTML for template conversion, this is the current focus of the API design. Feedback is always welcome though, so let us know if direct usage with Core is something of interest to you.
Better Handling of Broken PDFs
PDF viewers which are only concerned about representing the contents of PDF documents visually can be more lenient with documents with structural errors. However, since iText needs to read and manipulate PDFs at the lowest possible level (i.e., the actual “syntax”) while adhering to the PDF ISO specification, it cannot simply ignore such broken (or “corrupt”) PDFs.
Errors in cross-reference (xref) tables are a common reason for corrupted PDF documents, and iText will now provide more detailed log information when xref tables need to be rebuilt.
In addition, if iText situations such as encounters circular references in xref tables which cannot be resolved, it will now throw specific and more descriptive PdfExceptions rather than a generic NullPointerException.
Pull Requests
A bumper release for pull requests this time round, with shoutouts going to p3p3pp3 for submitting a fix for the Deflate.cs code, and renlinch for a rewrite of the PdfHtmlHeaderAndFooter.java example. Finally, thanks go to our old friend MatthiasValvekens for a correction to XMP URI serialization in PDF/A and PDF/UA files.
Bug fixes and miscellaneous
For this release, we’ve reviewed how iText will attempt to resolve issues in documents and fixed some bugs where documents were modified without first taking into account the
StrictnessLevelproperty.A discrepancy in the Java and .NET implementations of RSASSA-PSS support was found where the algorithm parameters for .NET were being ignored, leading to an incorrect signature. This is now fixed.
Finally, we upgraded our testing framework from JUnit 4 to JUnit 5, and adapted our automated tests.
... (truncated)
8.0.4
It’s time for the second release of 2024 of your favorite open-source PDF library for Java and .NET. This time the big news for iText Core version 8.0.4 is GraalVM Native Image support. Our devs have been hard at work on this feature for a while, and it’s something we’ve been pretty excited about!
In addition, we have further improved our PDF/UA support with new APIs, automated checks, and implemented the
IAccessibleElementlayout element for form fields.We've also enhanced iText's digital signature validation capabilities with improved OCSP logic, and the ability to parse document revisions.
GraalVM Native Image Support
As you can see on https://www.graalvm.org/native-image/libraries-and-frameworks/, the iText Core libraries are listed as tested with this technology.
If you’re not familiar with GraalVM Native Image, it is an ahead-of-time compilation technology - meaning that rather than running on a Java Virtual Machine, the code is compiled to a binary standalone executables. The neat thing about Native Image executables is they can offer several advantages over traditional JVM implementations:
Resource Efficiency: They are cheaper to run, since they use a fraction of the resources required by a Java Virtual Machine.
Fast Startup: Native Image executables start in milliseconds.
Immediate Peak Performance: They deliver peak performance immediately, with no warmup.
Efficient Deployment: Native executables can be packaged into lightweight container images for fast and efficient deployment.
Reduced Attack Surface: Since they only include the code required at runtime, native executables present a reduced attack surface.
GraalVM Native Image executables are ideal for containers and cloud deployments as they are small, start very quickly, and require significantly less CPU and memory. Furthermore, with profile-guided optimization, you can make GraalVM Native Image executables even faster.
As you can imagine, this opens up a world of possibilities for iText applications and we’re looking forward to seeing what you can do with it. So, if you develop anything cool, let us know!
Improved PDF/UA creation and checks
Following on from the general checks and helper logic for PDF/A and PDF/UA creation in the previous release, we’ve introduced some additional APIs for more user-friendly PDF/UA document creation - which you can see in action in our updated PDF/UA (Java/.NET) example. In addition, metadata for form fields can now be accessed and changed using the
IAccessibleElementlayout element.Not only that, we’ve also implemented a host of helpful automated checks to assist developers when generating conformant PDF/UA-1 documents. The idea is to guide developers and alert them with more descriptive exceptions if iText detects any missing tags or incorrectly tagged content.
We’ve followed the guidelines set out in the Matterhorn Protocol document, and while it is not (yet!) possible to identify all failure conditions in software alone, the additional detail in these exceptions will be a great help for developers to track down and resolve such issues.
Digital Signature Validation
Improved OCSP Validation
We’ve continued our work on the sign module by improving the logic of the OCSPVerifier class (Java/.NET). This class allows you to verify a digital certificate against one or more Online Certificate Status Protocol responses, which is useful when you want to determine the status of a certificate without requiring Certificate Revocation Lists (CRLs).
Read and Roll Back Document Revisions
We’ve added some functionality in the
kernelandsignmodules which enable iText to parse and gather the revisions to a signed document, and roll back to a previous version if necessary.Bug fixes and miscellaneous
We’ve improved the tagging for interactive form fields, and fixed a bug for list boxes where an infinite loop could result if the number of items exceeded what the page size would allow. In addition, there’s a couple of font-related fixes; one where the font changed after a special character, and one for not selecting an appropriate font if the character was neither first nor significant.
Other stuff
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)
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 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)