chore(deps): Bump itext7 from 8.0.5 to 9.6.0#8
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>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
dependabot
Bot
added
the
dependencies
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.5 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)
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)