Some backgrounds first
Typically, a PDF file consists of a header, body, cross reference information and a trailer, see Figure 2 below. When updating such a PDF file, you have a choice
- or re-built the entire document with all the integrated changes (which leads to the fact that the PDF is again formed as the original)
- or you can add changes to the body elements and cross-references to the document and add a new trailer that also refers to the previous trailer (resulting in a PDF file, as shown in Figure 3 below).
In fact, there are some forms between them. For instance. some tools simply cut off cross-references and the trailer of the original document, and then add new or changed body elements, new full cross-references and a new trailer without a link back to some previous state.
(Images copied from the PDF specification ISO 32000-1: 2008 )
In the case of creating PDF files, as in Figure 3, we have a history of various PDF states at hand, each of which starts from the beginning of the file and reaches one of the trailers and includes one of them. These states are usually called document revisions, and each document revision obviously reflects some state of the PDF information form, which I assume is what you call the AcroFields revision.
Unlike your assumption, these changes do not have a name as such. If you do not use the second part of the identifier (which should be different for different versions), but AFAIK, which is not used as a name for anything in iText.
There is some inaccuracy at the points where the trailer stops and the next body update begins. On the one hand, there are some options that are unavoidable in the specification (various possible line breaks, ignoring spaces, ignored comment lines), and on the other hand, many PDF manufacturers are slightly behind the specification. This, combined with the intermediate options between the full and incremental updates mentioned above, can make the process of pulling changes somewhat troublesome sometimes.
There is a special case of revisions that can be recognized with a high degree of reliability: Signed versions, that is, revisions, the latest update of which contains a built-in signature for the document. Since the signed ranges of bytes of the document should cover the entire revision of the document, but the gap for the signature itself (at least, must be accepted by Adobe software and comply with PAdES and PDF-2 standards), the exact end of the revision in this case can be inferred from the signature information:
More details here .
Some answers to your questions
I understand that every signature in a pdf is applied to a specific revision of AcroFields.
As mentioned above, each is applied to a specific revision of a document, which then implies a certain state or “revision” of the form data.
Each time the user changes an input (i.e. filling out the pdf form), a new revision is created.
Not necessary. As mentioned above, there are many intermediate methods for updating.
Only when changing information about a document, the latest version of which is signed, an appropriate incremental update is necessary if this signature should not be deleted or canceled. Otherwise, the updater can get all the information added after the last signature, create its own update with any content that it wants, and add this update to the last signed revision of the document. This update may even contain several blocks of virtual updates with the intention of making you believe that some intermediate changes do exist.
Thus, only signed versions can be somehow reliable to be true. iText only provides access to such signed versions.
My question is: how can I get all the changes from an AcroFields object?
You can retrieve all verified versions of a document using
InputStream revisionStream = fields.extractRevision("name");
and open them in separate instances of PdfReader . You can then access the PDF form information for each of these signed versions by requesting an AcroFields instance of the corresponding PdfReader open for that version.
(BTW, the String argument is not the name of the revision, but the name of the signature field whose signature matches that revision.)
But how can I get all versions (or their names, at least)? I have not found anything in the iText API and on the Internet.
As mentioned earlier, these change names are actually signature field names. So you can use
List<String> names = fields.getSignatureNames()
to get all the names for which a revision can be retrieved.