[
https://issues.apache.org/jira/browse/PDFBOX-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029638#comment-16029638
]
Tilman Hausherr commented on PDFBOX-3811:
-----------------------------------------
Yes, exposing a mutable object is what made me reconsider it all. I finally
found a very simple solution. Just get the byte range after {{addSignature()}}
like this:
{code}
int[] reserveByteRange = signature.getByteRange();
{code}
and reassign it later
{code}
document.getLastSignatureDictionary().setByteRange(reserveByteRange);
{code}
Your solution 2 can't be done because array writing format can't be influenced
easily.
> Problem with calling "saveIncrementalForExternalSigning" more than once in
> the same document
> --------------------------------------------------------------------------------------------
>
> Key: PDFBOX-3811
> URL: https://issues.apache.org/jira/browse/PDFBOX-3811
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
> Affects Versions: 2.0.6
> Environment: Java 1.8
> Reporter: Le Duc Duy
> Priority: Trivial
> Labels: easyfix, signature, signing
> Attachments: PDFBoxTest.java, Screen Shot 2017-05-26 at 6.39.10 PM.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I've included the test which will fail.
> After digging around a little, I found out that by calling
> saveIncrementalForExternalSigning, it trimmed the reserved space in the
> ByteRange (I've included the difference in the screen shot).
> I'm not sure if this is a bug for anyone but it's for my use case
> (distributed digital signing). Changing the content at all is not permitted
> at all.
> If this is an intended feature, please dismiss this. I can workaround by
> calling it more than once and it'll be stable although I'm not sure about
> efficiency.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
