[
https://issues.apache.org/jira/browse/PDFBOX-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751490#comment-15751490
]
Tilman Hausherr commented on PDFBOX-3631:
-----------------------------------------
Thanks for the itext file. I did find a possible clue. The problem file has its
original page dictionary in an object stream (ObjStm, not to confuse with XRef
stream). The pdfbox signing does not create any object streams, it just creates
ordinary objects, but itext does so (object streams help making the file a bit
smaller).
So maybe some products are overwriting their internal entries with the outdated
content of the ObjStm, despite that the updated object has already been read.
IMHO what we do is not forbidden, i.e. just because an object was in an object
stream before doesn't mean that its updated version must also be in an object
stream.
[~leonardr] can you give a comment on this? When doing an incremental update,
it is required that an updated object be in an ObjStm if the original object
was in an ObjStm ?
> Signature Interoperability Issue
> --------------------------------
>
> Key: PDFBOX-3631
> URL: https://issues.apache.org/jira/browse/PDFBOX-3631
> Project: PDFBox
> Issue Type: Bug
> Components: Signing
> Affects Versions: 2.0.3
> Environment: Java 1.8 Windows.
> Reporter: Marco Monacelli
> Priority: Minor
> Attachments: PDFBOX-3631.zip, PDFJS-4743-signature.pdf
>
>
> Some files if signed with PDFBox produce not visible signature in chrome,
> pdfium foxit.
> If the same file is signed on some Actobat, Foxit or itext the signature is
> visible.
> The test fle are inserted in an encrypted zip. If possible I would like to
> communicate the password with a private message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
