Bump itext7 from 9.5.0 to 9.6.0

[dependabot]

Updated itext7 from 9.5.0 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 WellTaggedPdfDocument subclass of PdfDocument, to join the existing PdfADocument and PdfUADocument classes. In addition, the PdfConformance class 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 WellTaggedPdfDocument to create a WTPDF document just like you would use PdfUADocument to 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)

Commits viewable in compare view.

[github-actions]

✅ Build validation completed successfully!

[github-actions]

✅ Build validation completed successfully!