Archiving and long-term storage / PDF/A-2b
PDF/A-2b: what archiving allows once it moves to PDF 1.7
The second part of the archiving standard, rebased on PDF 1.7, which quietly permits most of the things PDF/A-1 banned and is therefore the realistic target for a document produced from a stylesheet.
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 does not produce PDF/A-2b and cannot mark a file as part 2: the `pdf_a` option writes part 1, conformance B, and those values are fixed in the packet it emits. That is worth knowing before you turn the option on for a part 2 requirement, because the file will then carry a claim to be a stricter standard than the one you were asked for and will fail on rules that do not apply to you. What is genuinely different here is that your CSS is no longer the obstacle. The transparency your stylesheet produces is legal under part 2, so the remaining gap is the output intent and the fonts, both of which a converter can supply.
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.
- The same embedding, colour and metadata discipline as part 1: fonts in the file, an output intent for device colour, an XMP packet declaring pdfaid:part 2, and no encryption.
- Transparency is permitted, which is the change that matters most here, so opacity, rgba() colour, shadows and blend modes stop being automatic failures.
- JPEG2000 image data is permitted, as are object streams and cross-reference streams, so the file can be substantially smaller than the same document as part 1.
- Optional content groups are permitted, provided the default configuration is fully specified so a reader without layer support still shows the right thing.
- Embedded files are permitted, but only if the embedded file is itself a conformant PDF/A file. Anything else belongs in part 3.
- Digital signatures are permitted and are expected to follow the PAdES profile rather than being freeform.
Who asks for this
Records teams who have been through a PDF/A-1 project and found that half their documents failed on transparency. Part 2 is also what most modern archival policies specify now, because the 2005 standard predates almost everything a document is made with today. When a requirement just says PDF/A with a year attached, part 2 is usually what was meant.
What to do about it
Render normally, leave `pdf_a` off, and convert. Ghostscript will target part 2 with -dPDFA=2 and the same PDFA_def.ps pattern, and callas pdfToolbox and Acrobat preflight both have part 2 profiles that will fix colour and embed fonts in one pass. Because transparency survives, the converted file looks like what you rendered, which is not always true when the target is part 1 and the tool has to flatten.
How to check a file rather than assume
veraPDF with the 2b flavour. If you have a file that fails as 1b, run it again as 2b before doing any work: a good proportion of part 1 failures are transparency and nothing else, and the same bytes are already conformant against part 2. That five second check has saved entire remediation projects.
The mistake people make here
Converting to part 1 when the requirement said PDF/A and nothing more. Flattening transparency to satisfy the older standard changes the rendering, and on a document with shadows or a tinted overlay it changes it visibly. Ask which part before you flatten anything, because the answer is usually the part that would not have needed it.
Frequently asked
Does this API produce PDF/A-2b?
Not produced by this API. The API does not produce PDF/A-2b and cannot mark a file as part 2: the `pdf_a` option writes part 1, conformance B, and those values are fixed in the packet it emits. That is worth knowing before you turn the option on for a part 2 requirement, because the file will then carry a claim to be a stricter standard than the one you were asked for and will fail on rules that do not apply to you. What is genuinely different here is that your CSS is no longer the obstacle. The transparency your stylesheet produces is legal under part 2, so the remaining gap is the output intent and the fonts, both of which a converter can supply.
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.
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-2u and the Unicode rule behind broken text extraction
Level b plus one extra rule: every character in the document must map to a Unicode value, so the text can be searched, indexed and copied rather than merely looked at.
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/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.
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.
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.