I'm missing something here. The ByteRange entry for a signature is
initially set to something big enough to hold the eventual actual
ByteRange e.g.: "/ByteRange[1000000000 1000000000 1000000000 1000000000]
" followed by the /Contents<...> area.
After determining the correct ByteRange values, you _overwrite _the
/ByteRange entry in the file with a correct ByteRange. The size of the
overwrite must be exactly the size of the ByteRange entry starting.
Adding spaces at the end to ensure that the /Content area starts at
exactly the byte number that it started before, e.g: "/ByteRange[ 0 4527
9361 34523] "
For any given signature you only need to consider the ByteRange for that
signature. I don't understand why you think you need to check /ByteRange
entries for any other signature. With respect to this signature, the
others are just data and part of the hash.
Now you hash the entire file based on the /ByteRange you have specified.
Generate the signature, and put it into the preallocated /Contents area
(via _overwrite_)
All of this is done after (incrementally) saving the file. Moving
anything around will break the Xref table.
Marc
On 9/4/2025 5:07 AM, Coetmeur, Alain wrote:
I succeed in making the saveIncremental() work, but the signature is invalid,
because of the /ByteRange is not consistent (Acrobat Reader and DSS do moan
when verifying)...
<Indication>FAILED</Indication>
<SubIndication>HASH_FAILURE</SubIndication>
<Errors Key="BBB_FC_IBRV_ANS">The /ByteRange dictionary is not
consistent!</Errors>
<Errors Key="BBB_CV_IRDOI_ANS">The reference data object is not intact!</Errors>
So I'm wrong (before signing PDF say the file is OK, so it must be my patch).
My modification, base on 4.0.0-SNAPSHOT trunk is, just taking the maximum for
byteRangeLength , thus in fact always 35:
...
