Archiving and long-term storage / PDF/A-2u
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.
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 has no option that affects text encoding and no way to attach or repair a ToUnicode map. This is the archival page where your font choice does the deciding: a font served through @font-face as a normal subsetted web font almost always carries usable Unicode mapping, while an icon font, a font with a private use area, or text drawn as outlines by a charting library carries none at all. Since no API option pins this, the only reliable way to know about a given document is to extract its text and read what comes out.
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.
- Everything PDF/A-2b requires, with no relaxation.
- A ToUnicode CMap for every font used for showing text, or an encoding that is unambiguously mappable to Unicode without one.
- Correct mapping rather than merely present mapping: a font whose ToUnicode table maps every glyph to the same character satisfies the letter of nothing and fails the check.
- Ligatures and composed glyphs mapped to the sequence of characters they stand for, so a fi ligature extracts as two letters.
- No requirement for a structure tree, headings or alternative text. That is level a, and 2u deliberately stops short of it.
- The XMP packet declaring pdfaid:part 2 and pdfaid:conformance U.
Who asks for this
Anyone who has to find documents again. Legal discovery platforms, e-invoicing archives and any records system with full text search all care about level u, because a page of text that extracts as gibberish is invisible to the index even though it looks perfect. It is the level to ask for when the real requirement is searchability and somebody has written PDF/A-2a because they assumed more letters meant more of what they wanted.
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.
# Does the text come out as text? Read the answer before doing anything else.
pdftotext -layout invoice.pdf - | head -40
# Then check the file against the standard it claims.
verapdf --flavour 2u invoice.pdf
# A non-zero exit means at least one rule failed. The report names the clause
# and the object, which is what tells you which font is missing its mapping.What to do about it
Test before you build the pipeline. Render the document, extract the text, and look at it: if it comes back correct, level u is a metadata and output intent problem that a converter handles, and if it comes back as boxes or the wrong letters, no converter can fix it because the information is not in the file. Replace the offending font or render that content as real text rather than as paths, then convert.
How to check a file rather than assume
Two checks, in this order. Extract the text with pdftotext or qpdf and read it, because that is the failure a person will actually experience. Then run veraPDF with the 2u flavour, which reports the missing or non-injective mappings against the clause rather than leaving you to guess which font is at fault.
The mistake people make here
Trusting a visual check. Text rendered from a subsetted font with a broken mapping looks exactly right on screen and on paper, and the problem only surfaces months later when somebody searches the archive and finds nothing. Copy a paragraph out of the PDF and paste it somewhere before you sign off on a pipeline.
Frequently asked
Does this API produce PDF/A-2u?
Not produced by this API. The API has no option that affects text encoding and no way to attach or repair a ToUnicode map. This is the archival page where your font choice does the deciding: a font served through @font-face as a normal subsetted web font almost always carries usable Unicode mapping, while an icon font, a font with a private use area, or text drawn as outlines by a charting library carries none at all. Since no API option pins this, the only reliable way to know about a given document is to extract its text and read what comes out.
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-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.
Why an archival PDF has to embed every font it uses
Every conformance standard requires the actual font program to be inside the file, because a font named but not embedded is a promise that some other machine will have it, and archiving exists precisely because that promise fails.
Checking a PDF really is PDF/A before you trust it
Conformance is a property of the bytes, not of the metadata that claims it, and the only way to know which one you have is to run the file through a validator that reports clauses.
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.