I noticed a behaviour I don't understand with some PDFs. They are hybrid-reference file where both cross-reference sections carry the same informations (there are 9 meaningful objects and the 9 are referenced by both sections).
When I sign the document twice, the second signature invalidates the first one. This seems to be due to the copy in the update trailers of the reference to the original cross-refernce stream, i.e. :
<</XRefStm 78305/ [...]>>
Is this a bad practice?
It’s hard to understand what you mean.
Are you saying that you have a file which started out as compressed object/xref streams and was then updated using classic xrefs? If so, that’s going to be a problem as it’s not fully supported according to the standard. (sort of like Ghostbusters – don’t mix the streams!)
If you are signing such a file (or any non-signed PDF for that matter), it’s always a good idea to a “full, garbage collected” save first. THEN sign away.
As a picture is often better than a long speech, here is the mess:
10 0 obj
<</Type/XRef/Size 10/W[ 1 4 2] /Root 1 0 R/Info 7 0 R/ID[<FAC18A20B074DF4FA664118D8354A667><FAC18A20B074DF4FA664118D8354A 667>] /Filter/FlateDecode/Length 46>>
% stream data
0000000000 65535 f
0000000017 00000 n
0000000078 00000 n
0000000134 00000 n
0000000354 00000 n
0000000476 00000 n
0000000642 00000 n
0000000880 00000 n
0000001111 00000 n
0000001137 00000 n
0000078305 00000 n
<</Size 11/Root 1 0 R/Info 7 0 R/ID[<FAC18A20B074DF4FA664118D8354A667><FAC18A20B074DF4FA664118D8354A 667>] >>
<</Size 11/Root 1 0 R/Info 7 0 R/ID[<FAC18A20B074DF4FA664118D8354A667><FAC18A20B074DF4FA664118D8354A 667>] /Prev 78550/XRefStm 78305>>
Well, this seems to be what you suggested: mixed streams. Unfortunatly I can't rewrite the file entirely as my tool cannot produce PDF from scratch.
I found as a workaround that updating the file with standard cross-reference table does not invalidate signatures.
Thank you Leonard for your help!
Europe, Middle East and Africa