Archiving and long-term storage / PDF/A-4
PDF/A-4: the conformance letters are gone, what replaced them
The 2020 rebase onto PDF 2.0, which drops the a, b and u conformance letters entirely, makes Unicode mapping mandatory for everyone, and splits the optional extras into two named variants instead.
Where this API stands
This API does not produce this standard, and there is no option that would. What follows is what the requirement actually is and where a rendered document stands against it. The API cannot mark a file as part 4. The `pdf_a` option writes part 1 conformance B and nothing else, so turning it on for a part 4 requirement produces a file claiming the wrong standard. There is nothing subtle to say about your markup here that is not already true of part 2, because the visible-document rules are substantially the same. The difference that matters is which validator flavour you will eventually be judged against.
What the standard requires
The requirements as a checker enforces them, rather than as a procurement document paraphrases them. A file satisfies all of these or it satisfies none of them.
- Unicode mapping for all text, unconditionally. What used to be level u is now the baseline and there is no level below it.
- Fonts embedded and an output intent present, as in every earlier part.
- An XMP packet declaring pdfaid:part 4 and pdfaid:rev with the revision year, rather than pdfaid:conformance. This trips up tooling written for the older parts.
- Tagging is not required. If a structure tree is present it must be valid, which is a real change from part 1 where level b simply ignored the question.
- PDF/A-4f is the variant that permits embedded files of any type, taking over what part 3 did, and it sets pdfaid:conformance to F.
- PDF/A-4e is the engineering variant permitting rich media and 3D annotations, replacing PDF/E-1, and it sets pdfaid:conformance to E.
Who asks for this
Very few people yet, and that is the useful thing to know. Part 4 is the current standard and the one to specify for new systems, but portals and validators in the field were built against parts 1 to 3 and a good number of them will reject a part 4 file as malformed rather than as non-conformant. Ask what the receiving system actually validates before choosing it.
What it looks like in a file
The concrete form of the thing being described, so you can recognise it in a document you have been handed rather than only in a specification.
<rdf:Description rdf:about=""
xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
<pdfaid:part>4</pdfaid:part>
<pdfaid:rev>2020</pdfaid:rev>
</rdf:Description>
<!-- Part 4 has no conformance letter on the base profile. A packet that pairs
part 4 with a conformance of A, B or U was written by a tool that has not
been updated, and identification fails before any content is checked.
The letters F and E do appear on part 4, but only for the embedded-file
and engineering variants. -->What to do about it
Render, then convert with a tool that has caught up. Recent Ghostscript releases and current callas and Acrobat builds target part 4; older ones silently do not, and a tool that writes pdfaid:conformance instead of pdfaid:rev has produced a file that fails identification. Check the tool version before the file.
How to check a file rather than assume
veraPDF has 4, 4f and 4e flavours and is the reference for all three. Read the identification metadata as well as the validation result: exiftool will show you the pdfaid fields directly, and seeing part 4 next to a conformance letter rather than a revision year tells you immediately that the writing tool is out of date.
The mistake people make here
Specifying part 4 in a contract because it is the newest number. If the counterparty's intake system was written in 2014, the newest number is the one that fails. Pick the part the receiver validates, then say so explicitly, including the conformance level where the part still has one.
Frequently asked
Does this API produce PDF/A-4?
Not produced by this API. The API cannot mark a file as part 4. The `pdf_a` option writes part 1 conformance B and nothing else, so turning it on for a part 4 requirement produces a file claiming the wrong standard. There is nothing subtle to say about your markup here that is not already true of part 2, because the visible-document rules are substantially the same. The difference that matters is which validator flavour you will eventually be judged against.
Can I turn on the pdf_a option and be done?
No. The option writes an XMP packet declaring PDF/A-1b into the document catalogue, and the render response comes back carrying a warning that says in as many words that this is best-effort and that full conformance requires tagged structure and an embedded ICC profile. It is a claim written into the file, not a certificate earned by it, and a validator checks the claim against the bytes. Read the warning array in the response rather than taking the absence of an error as a pass.
Should I convert before rendering or after?
After, always. A conformance converter rewrites colour, embeds profiles, sets boxes and stamps metadata on a finished PDF. Trying to satisfy a conformance target from the source side means guessing at what the converter would have done, and the guesses that go wrong are expensive: flattening transparency you did not need to flatten changes what the page looks like.
Standards this one is confused with
The neighbours that matter are the ones people mistake for this, not the ones that sort next to it.
PDF/A-3: an archival PDF with a data file inside it
Part 2 with one rule removed: an embedded file no longer has to be a PDF/A file itself, which is what makes a hybrid invoice carrying both a printable page and a machine-readable XML payload possible.
PDF 2.0 and what changed in ISO 32000-2
ISO 32000-2, the first version of PDF published by ISO without an Adobe specification behind it, and the base for PDF/A-4.
PDF/A levels a, b and u, and which one you were asked for
PDF/A on its own is not a specification: it is four parts crossed with up to three conformance levels, and the combination decides whether your job is a converter setting or a month of manual tagging.
What PDF/A-1b requires, and how far this API gets you
The oldest and strictest archiving profile: a PDF 1.4 file with everything it needs to render sealed inside it, and nothing in it that a future reader might not understand.
PDF/A-1a: the tagging requirement that 1b does not have
Everything PDF/A-1b requires, plus a complete logical structure tree, a declared document language and a Unicode mapping for every glyph, so the file is readable by a machine and not only by an eye.
Every standard, with what this API does about it
The full list, grouped by what the requirement is for, each marked with how far this API gets.
What this API actually does
One page per option and endpoint that exists, with nothing that does not.
Conformance is decided after a file exists. Render the document, then check it, then convert only what the checker actually flags.