I have a PDF/A compliant document and i want to sign it - but the PDF/A
compliance should not be lost. A signed PDF can not changed after the
signature was applied otherwise the signature gets invalid.
So if
a want to sing a PDF which is already PDF/A compliant - the signature
must also follow the PDF/A rules - e.g. for the XMP metadata and for the
transparency of e.g. the visual signature.
Is your product able to apply a PDF/A compliant signature to be able to generate signed PDF/A documents.
This
has nothing to do with PDF to PDF/A conversion - this is only a
question if the signature which is applied follows the PDF/A rules to do
not destroy the PDF/A compliance of an already PDF/A compliant
document.
Attached you can find an already PDF/A compliant test
page which i want to sign - visible or invisible and the PDF/A
compliance should not be destroyed by the sign process.
I made tests with the actual version and used a valid PDF/A 1b document and added a (visible) signature to the document.
By
adding the signature the document which was PDF/A compliant is not
longer PDF/A compliant after the signature was added by the Aspose
toolkit.
So it seems that you are not able to add a PDF/A
compliant signature to a document and when a document is already PDF/A
compliant this is destroyed by the sign process.
e.g. invisible
signature - the signature process generates 3 PDF/A errors - see
attached screen shots - because the sing process changes the pdf
properties - and the changes are not written to the XMP metadata - but
this is needed to keep the PDF/A compliance of the document - that the
pdf document properties are in sync with the information in the XMP
metadata of the PDF.
The 3 errors means
1.) the creator in the document properties is different from the creator in the XMP data
2.) The last change date in the document info and the XMP matadata are not the same
3.) not the same information for the creator in the document properties and in the XMP metadata.
So this means that the processing by the Aspose component wrote new
information to the document information properties and the same changes
must be also done in the XMP meta data - because for the PDF/A standard
they must be synchronous and can not be different.
If they are automatic written and the signature function does not
take care of the synchronization between the document info properties
and the XMP - and this is one step during the signature - this can not
be modified later because then the signature gets invalid.
When the signature function does not take care of this to also
update the XMP metadata during the sign process the PDF/A compliance is
lost when apply the signature.
<br><br>Will there be a solution for this to keep the PDF/A compliance when adding a signature ?<br><br>