We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Signing a PDF/A document - do not loose the PDF/A compliance

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>

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.

Is this possible with your actual version of the PDF component ?


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.







This problem also happens with the last version 8.0 - and when adding a visible signature an other PDF/A error is added - the visiable signature which is added as image - is added with transprency and this is not allowed by the PDF/A-1 standard. So also this destroys the PDF/A compliance and the result is a singed PDF document but not longer a valid PDF/A




Hi,


Thanks for contacting support.

I am working over this query and will get back to you soon. We are sorry for this delay and inconvenience.