iText 9 Signing Improvements
In iText 9, we’ve made several important updates to improve the creation and handling of signature form fields, ensuring better PDF/UA compliance and a smoother developer experience. Previously, when signing a document that did not have any available signature fields, causing a new one to be created, the AlternativeDescription
set in the GetAccessibilityProperties
of the appearance of the new signature field was not considered.
This omission led to a missing description entry (known as the Tooltip or TU entry), which is crucial for accessibility. Without it, the document fails PDF/UA validation, making it non-compliant. Modifying the form field properties requires developers to override methods, which can quickly become complicated and unintuitive.
Additionally, past versions did not alert users when a font was not set for the SignatureAppearance
when working with PDF/UA documents. Previously, this would result in a PropertyError
rather than a more informative PDF/A or PDF/UA compliance exception.
In our latest release, these challenges have been addressed, and creating a signature form field now correctly incorporates the AlternativeDescription
, helping ensure your documents meet PDF/UA standards more easily.
We’ve also enhanced the way SignatureAppearance
handles font settings, offering clearer warnings to prevent confusion and reduce errors while creating accessible documents.
Code
To sign PDF/UA documents, we’ll need to inherit from the PdfSigner
(Java/.NET) class to create a PdfUaSigner
that is instantiated with the PdfUaDocument
(Java/.NET) object. Below you can find a simple example implementation for this.
Once the PdfSigner
is properly instantiated with a PdfUADocument
, we can follow the normal signing workflow as described in our Digital Signing with iText series on the Knowledge Base. The PdfUaDocument
will ensure PDF/UA is being adhered to during document generation.