PDFPipe

Archiving and long-term storage / PDF/A-1a

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.

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. This API produces nothing towards level a and has no option that could. There is no tagging control, no way to set the document language in the catalogue, and no way to attach alternative text to an image through the API surface. What matters on your side is different from the other archival pages: the semantics of the source markup are the raw material a tagger works from later, so a document built from real headings, a real table with header cells, real lists and images with meaningful alt attributes is convertible, and one built from styled divs is not. The API exposes no control over whether output is tagged, so if you need to know about a particular file, run a checker on it rather than assuming either answer.

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 full PDF/A-1b rule set, unchanged. Level a is additive: it never relaxes anything.
  • A structure tree rooted at StructTreeRoot, with every piece of real content marked and placed in it in the order a person would read it.
  • A natural language declared for the document in the catalogue, and for any run of text that differs from it.
  • An alternative description on every image, formula and other non-text object that carries meaning.
  • A ToUnicode mapping for every font, so selecting the text and pasting it produces the characters that were printed rather than glyph indices.
  • Decorative content marked as an artifact so it is skipped rather than read aloud.

Who asks for this

Anyone whose archiving requirement was written by the same person who wrote the accessibility requirement, which is increasingly common in public sector work. Level a is also what gets specified when somebody copies a requirement from a legal deposit library, because a national library wants text it can index and not just pictures of pages. If you have been handed level a and the document is generated rather than authored, this is the requirement that actually costs money.

What to do about it

Accept that level a is a document authoring problem rather than a rendering setting. If the source is yours, write the markup semantically and then tag with a tool that reads it, or generate the tagged PDF directly with a library that writes structure. If the file already exists untagged, Acrobat's autotag will produce a tree and it will get the reading order wrong on anything with columns or a sidebar, so budget for a person to fix it in the tag panel. Nothing automated can infer that a floated box is a caption rather than the next paragraph.

How to check a file rather than assume

veraPDF with the 1a flavour will catch the structural and metadata failures, and it is the right first gate because it is objective. It will not tell you the reading order is wrong, only that an order exists. For that you need PAC, which reports the tag tree as a screen reader would walk it, or you read the document aloud with a real screen reader, which is slower and more convincing.

The mistake people make here

Assuming a validator pass means the document is accessible. Level a checks that a structure tree is present and well formed. It cannot check that the tree matches the document, so a file where every paragraph is tagged as a heading passes cleanly and is useless. The tagging is the mechanism, the reading order is the point, and only one of them is machine checkable.

Frequently asked

Does this API produce PDF/A-1a?

Not produced by this API. This API produces nothing towards level a and has no option that could. There is no tagging control, no way to set the document language in the catalogue, and no way to attach alternative text to an image through the API surface. What matters on your side is different from the other archival pages: the semantics of the source markup are the raw material a tagger works from later, so a document built from real headings, a real table with header cells, real lists and images with meaningful alt attributes is convertible, and one built from styled divs is not. The API exposes no control over whether output is tagged, so if you need to know about a particular file, run a checker on it rather than assuming either answer.

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.

Conformance is decided after a file exists. Render the document, then check it, then convert only what the checker actually flags.