Bump itext and itext.pdfhtml

[dependabot]

Updated itext from 9.5.0 to 9.6.0.

Release notes

Sourced from itext'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.

Updated itext.pdfhtml from 6.3.1 to 6.3.2.

Release notes

Sourced from itext.pdfhtml's releases.

6.3.2

pdfHTML is an iText Core add-on for creating PDF from HTML/XML (and associated CSS).

For this release we took the opportunity to reflect the improved Well-Tagged PDF (WTPDF) creation in iText Core 9.6.0 to enable WTPDF conformance support in pdfHTML. We also added support for one CSS pseudo-class, and improved the implementation of another, along with some more minor refinements and bug fixes.

As noted in the Mozilla Developer Network documentation, the :has() pseudo-class matches an element when the selector inside finds a match relative to that element. In simple terms can be called a “parent selector”, as it allows you to style a parent (or even an element that comes before another) based on what it contains or comes after it.

We actually added this to help with the release-notes-to-pdf generator we recently open-sourced, as we found it would be useful when referencing the table of contributors to a specific release version. Hopefully someone else will find it useful too!

The other pseudo-class is the :not() selector for the @​page at-rule. You can now specify @​page :not(:first) to apply styles to all pages except the first page, whereas before it behaved incorrectly.

We’ve refactored how pdfHTML handles dependency injection, related to the changes to make StampingProperties and DocumentPropertiesstateless in iText Core 9.6.0:

• ConverterProperties now stores dependency suppliers instead of dependency instances, and new methods to access dependency classes and retrieve a dependency’s supplier have been introduced.
• ProcessorContext was updated to register dependencies using the new supplier-based API, while the old getDependencies() API is now marked as deprecated and returns fresh instances created via suppliers.

An issue with positioning of elements (such as list items) being lost when the block is split across pages was resolved, along with an issue with HTML tables using collapsed borders with large rowspans that overflow/split onto a new page.

Bug Fixes

• DEVSIX-9700 – Support css :has pseudo class
• DEVSIX-9767 – Add WTPDF creation using pdfHTML

Improvements

• DEVSIX-9613 – Make DocumentProperties/StampingProperties stateless

Bug Fixes

• DEVSIX-2431 – Positioned elements (e.g. absolute positioning) are lost when block is split across pages
• DEVSIX-5036 – Original rowspan is restored while overflowing to the next page
• DEVSIX-9715 – Absolutely positioned elements can be dropped when parent block-element is split across pages.
• DEVSIX-7094 – Page selector is applied even though :not is specified

Commits viewable in compare view.