Thanks a lot for your reply!

I’ve tried to debug as you suggested.

When we “prepare” the document, adding the new signature field before calling 
the “saveIncrementalForExternalSigning” PDDocument’s method, this segment is 
reached twice (first for the old signature and second for the new added one). 
Afterwards the COSWriter “doWriteSignature” (the one that in the second “round” 
will throw the Exception) method is only called once for the new signature. 
After the “external” signature is added 
(pbSigningSupport.setSignature(externalSignature)) and the “saveIncremental” 
method is called, this segment is only reached once (for the old signature) and 
so also the "“doWriteSignature” method (always for the old signature).
Comparing the properties of the old signature between the two calls inside this 
segment for the old signature, I can see that the byteRangeArray, 
byteRangeLength and signatureLength remain unchanged, only the offsets are 
different. Inside the doWriteSignature method then the byteRangeArray object is 
changed with the new offsets and the resulting byteRange String is one 
character longer as it was before and therefore the exception is thrown.

Thanks again and best regards

Patrick



> On 23 Sep 2022, at 17:37, Tilman Hausherr <thaush...@t-online.de> wrote:
> 
> 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
>>  
>> <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 
> <mailto:users-unsubscr...@pdfbox.apache.org>
> For additional commands, e-mail: users-h...@pdfbox.apache.org 
> <mailto:users-h...@pdfbox.apache.org>

Reply via email to