PdfSigner now correctly detects and creates PDF/A documents
What changed?
In previous iText versions, when a PDF was signed, iText did not check whether a given document was a PDF or PDF/A document. This prevented the PdfSigner from properly initializing the document as a PdfADocument (Java/.NET) if required. In our 7.2.4 release, the PdfSigner (Java/.NET) in the signatures module was changed to detect whether a document claims PDF/A conformance and it will now initialize the correct PdfDocument object accordingly.
PdfSigner did not enforce PDF/A compliance on documents that claimed conformance. Whereas now, an exception will be thrown if any content is added in a way that does not conform to the PDF/A standard present on the document before the signing process started.
How it works
When signing a PDF/A document with the iText 7.2.4 signing module, a PdfADocument will be created. That means if you add content to the document iText will now run the relevant checker, such as PdfA1Checker (Java/.NET) for example, against the content you're adding to check whether it complies with the chosen PDF/A standard. This happens automatically and requires no additional code to be added.
A practical example of this would be a scenario where a signature appearance is created, or additional content is added to the document during the signing process without using a fully embedded font, for example. Not properly embedding a font breaks PDF/A compliance and PdfSigner would previously just create the document as is but with this new change an exception will be thrown to prevent creating a non-compliant PDF/A document. For non-embedded fonts, the exception caused would state: "All the fonts must be embedded. This one is not: name-of-font".