Why Default Appearance is created for an empty signature field?

[bsanchezb]

Describe the bug As initially reported in DSS-2691, OpenPdf adds /DA and /DR dictionaries in an empty signature field creation, when using the method PdfStamper.addSignature(...). This is caused by the line PdfStamper.java#L483, reason for which execution is not clear. The line causing the issue is copied below:

acroForm.drawSignatureAppearences(signature, llx, lly, urx, ury);

The problem is, as the result, an empty signature field is being created with a pre-configured font settings, which are not necessary will be used after the signature creation. This may cause an incompliance to a PDF/A specification for a produced document.

To Reproduce

// get Stamper

PdfStamper stp = ....
stp.addSignature(...);
stp.close();

Expected behavior We would like to know the reason why the Default Appearance is being added to an AcroForm for an empty signature field, not containing any visual data? As defined in ISO 32000-1, the fields /DA and /DR are optional for the AcroForm dictionary, therefore there is no strong requirement for its addition. Moreover, removing of the line does not seem to be causing any issues with existing unit tests available in OpenPDF project, nor in our testing. Thus, we would appreciate any comments regarding this topic. If it is not necessary, to my opinion, it would be advisable to remove signature appearance drawing from PdfStamper.addSignature(...) and PdfAcroForm.addSignature(...) methods as a default behavior.

System (please complete the following information): OpenPdf 1.3.26

Additional context To demonstrate the difference between two documents created with and without executing the #drawSignatureAppearences method, I attach two PDF documents to this ticket.

new-pdf-with-da.pdf (with #drawSignatureAppearences) new-pdf-without-da.pdf (without #drawSignatureAppearences)

Best regards, Aleksandr.

[andreasrosdal]

Thanks for reporting this. Pull requests welcome.

[ThreeHmeng]

Hello @bsanchezb , our group are interested in this issue, and we will try to fix it. ---- SE_SUSTech, group: Lanrand

[bsanchezb]

Hello @ThreeHmeng ,

That sounds great!

For your additional information, it seems like my first idea, mentioned in the first message, was a bit too optimistic. Actually, the idea to skip #drawSignatureAppearance method is bad, as it draws a normal appearance, which is actually required in PDF/A or PDF-2.0. The problem is /DA and /DR dictionaries created in the same steps. I tried to configure their creation only when a visual data has been provided, however the /DA and /DR dictionaries have been skipped even when signing an empty field with a visual signature, where it should be enforced. Therefore, I decided to not propose a PR.

Anyway, we would appreciate any good fix for this issue.

Best regards, Aleksandr.

[mkl-public]

Two remarks:

• A default appearance (DA) entry does not make sense for signature fields. Default appearances are only meaningful for text fields. Signature fields are no text fields.

• A default resources (DR) AcroForm entry is not per se bad. What makes it bad in the case at hand is the font OpenPDF adds to it as it is invalid for PDF/A use. (One might argue that that the font is not actually used anywhere and, therefore, shouldn't count. On the other hand fonts in DR are meant for use in form field appearances, so there is good reason for inspecting everything therein.)

  Creating a DR entry without a font is no option, either, as the default resources - if present at all - are required to contain at least a font as default for displaying text.