Your screenshots didn't get through. This works with Thunderbird but not
with other mail software that doesn't do real inline images. You'd have
to upload to a sharehoster.
Even then, I doubt I will have any solution based on these screenshots
because these won't answer the problem / suspicion I mentioned.
Yes this UR3 thing is an Adobe feature (but then, whole PDF is).
Incremental saving means that the original PDF stays like it is, but
that new data is appended at the end of the file. That's why I was
surprised that the byte range of that UR3 signature was within the
incremental segment, instead of being in the original segment only.
(post 01.09.2025, 14:53)
Tilman
Am 16.09.2025 um 19:09 schrieb Coetmeur, Alain:
I have used PDFBOX-app 4.0.0 debug and this clarify the structure...
Here is attached the capture of the tree for internal data for the document
before signing with DSS as PADES
the signature in "Perms/UR3/Contents" is PKCS7 signed data, signed by this
certificate
CN=ARE Acrobat Product v8.0 P23 0002337
OU=Adobe Trust Services
O=Adobe Systems Incorporated
C=US
Maybe you will understand the purpose of that Perms/UR3 signature ?
It seems to be an Adobe functionality.
I cannot debug the result since the Pades signature fails and returns nothing.
However, I have signed with the older DSS, using PDFBOX2.x, which works well
and here is the capture of the tree of the resigned in PADES document
the problem seems to be that the ByteRange are slightly different, and the
difference lead to a difference in the number of digits, thus the length of the
field.
What I don't understand is why when I try to force the maximum length for
ByteRange field for the Acroform/Field/0/V, it breaks the Perms/UR3 signing.
But I don't understand what is the incremental saving... PDF is very subtle.
Alain
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
