Hi,
do I understand it correctly that you get an already signed document
which when opened causes the Adobe Reader message?
You are trying to sign that document a second time?
If you can't provide such a document for testing (which would be the
best option) I can propably generate such a sample document.
BR
Maruan
Am Montag, dem 26.09.2022 um 20:22 +0200 schrieb Tilman Hausherr:
> Hi,
>
> How come that you're reaching something COSWriter before saving? And
> why
> are saveIncrementalForExternalSigning and saveIncremental called?
>
> Is it because you first have the signature, and then the LTV as an
> extra
> step?
>
> I'm wondering if this code segment
>
> if (incrementalUpdate)
> {
> if (signatureOffset == 0 || byteRangeOffset == 0)
> {
> doWriteIncrement();
> }
> else
> {
> doWriteSignature();
> }
> }
>
> properly distinguishes whether one is signing or doing an incremental
> saving without signing anything. Could it be that doWriteSignature is
> called when it shouldn't? (Maybe you were saying just that all the
> time,
> it's difficult for me to imagine what happens without the file,
> despite
> that you explained a lot)
>
> Tilman
>
> On 26.09.2022 09:45, Patrick Herber wrote:
> > 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 <[email protected]>
> > > 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(COSWrite
> > > > r.java:763)
> > > > at
> > > > org.apache.pdfbox.pdfwriter.COSWriter.visitFromDocument(COSWrit
> > > > er.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(PdfDoc
> > > > ument.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/sant
> > > > ander_freistellungsauftrag_modified.pdf <
> > > > https://issues.apache.org/jira/secure/attachment/12744154/santa
> > > > nder_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:
> > > [email protected] <mailto:
> > > [email protected]>
> > > For additional commands, e-mail:
> > > [email protected] <mailto:
> > > [email protected]>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
--
--
Maruan Sahyoun
FileAffairs GmbH
Josef-Schappe-Straße 21
40882 Ratingen
Tel: +49 (2102) 89497 88
Fax: +49 (2102) 89497 91
[email protected]
www.fileaffairs.de
Geschäftsführer: Maruan Sahyoun
Handelsregister: AG Düsseldorf, HRB 53837
UST.-ID: DE248275827
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
