I remember we had this problem before but I can't remember how it was
fixed. Currently we consider the first signature we hit. I remember
thinking about this and concluding that the algorithm would always hit
the first one and not an old one.
It's difficult without the file. You'll have to debug this yourself by
looking at the reachedSignature field in COSWriter. Maybe the "If we
reach the pdf signature" segments are hit twice. If you can build from
source, then put debug output in that segment to find out if
if(reachedSignature && COSName.BYTERANGE.equals(entry.getKey()))
is reached twice.
Tilman
On 23.09.2022 10:23, Patrick Herber wrote:
Dear PDFBox community
We use PDFBox (version 2.0.26) for signing documents and we are currently
facing a problem signing a particular document (however, this doesn’t seem to
be an isolated case, since in the past we received the notification of similar
error messages, but we couldn’t have access to the affected documents).
This document already contains a filled form and a signature (with LTV support) and
when you open the document with Acrobat Reader you get the message: "This
document enabled extended features in Adobe Acrobat Reader. The document has been
changed since it was created and use of extended features is no longer available.
Please contact the author for the original version of this document.”
Now, when we try to sign it, also using an LTV-enabled signature (Advanced or
Qualified), we receive following error message:
java.io.IOException: Can't write new byteRange '0 542575 554377 7562]' not
enough space: byteRange.length(): 21, byteRangeLength: 20
at org.apache.pdfbox.pdfwriter.COSWriter.doWriteSignature(COSWriter.java:763)
at org.apache.pdfbox.pdfwriter.COSWriter.visitFromDocument(COSWriter.java:1199)
at org.apache.pdfbox.cos.COSDocument.accept(COSDocument.java:452)
at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1435)
at org.apache.pdfbox.pdmodel.PDDocument.saveIncremental(PDDocument.java:1412)
at
com.swisscom.ais.client.impl.PdfDocument.finishSignature(PdfDocument.java:180)
... 4 more
Instead adding a simple timestamp (without LTV) it works without issues.
The byteRange length referred in the stack trace is the one of the OLD
signature and not of the one we are adding to the document (please note that
for the new one we reserve a size of 30’000 bytes, and also increasing this
size has no impact).
Unfortunately I’m not allowed to share with you this document (I’m trying to
arrange the creation of a new sample document with the same properties, but the
author of the file is currently in holiday).
In the PDFBox Jira I’ve found some already solved issues regarding
saveIncremental and these “extended features”:
https://issues.apache.org/jira/browse/PDFBOX-45
https://issues.apache.org/jira/browse/PDFBOX-2857
https://issues.apache.org/jira/browse/PDFBOX-2858
https://issues.apache.org/jira/browse/PDFBOX-2859
In one of these issues (PDFBOX-2858), I found a file example (santander_freistellungsauftrag_modified.pdf <https://issues.apache.org/jira/secure/attachment/12744154/santander_freistellungsauftrag_modified.pdf>). I’ve try to sign it (and also countersign it) but “unfortunately” also this one worked without any issue.
Can you kindly help me solving this problem?
Thanks and best regards,
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
