Reference
PDF conformance standards, and which ones this API produces
This API renders HTML to PDF. It exposes one conformance-related option, pdf_a, and that option writes a PDF/A-1b identification packet into the document and returns a warning saying the marking is best-effort. There is no PDF/X mode, no PDF/UA mode, no output intent, no ICC embedding and no tagging control.
So most pages below say, in their first section, that the API does not emit the standard. That is the point of the cluster rather than a gap in it. If you have been handed an archiving or accessibility requirement, what you need is what the requirement actually is, what would have to be true of a file to satisfy it, and how to check rather than assume. A page that implied conformance would cost you a failed audit instead of an afternoon.
For what the API does do, see the capability reference. For the styling decisions that decide whether a file is convertible at all, see CSS for paged documents.
Archiving and long-term storage
PDF/A exists so a file opens the same way in thirty years as it does today. Everything it requires follows from that one goal: no external dependencies, no ambiguity about colour, and enough metadata inside the file to identify what it claims to be.
- PDF/A-1bPartly, and the page says how far
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-1aNot produced by this API
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-2bNot produced by this API
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.
- PDF/A-2uNot produced by this API
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-3Not produced by this API
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-4Not produced by this API
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.
- PDF/A conformance levelsPartly, and the page says how far
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.
- Output intent and ICC profileNot produced by this API
A dictionary in the document catalogue holding an embedded colour profile, which is what turns an otherwise meaningless triple of numbers into a colour a future reader can reproduce.
- Embedded fonts in an archival PDFPartly, and the page says how far
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.
- Validating a PDF/A fileA step after rendering
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.
Accessibility and structure
PDF/UA and tagged PDF are about a second, invisible copy of the document: a tree of headings, paragraphs, lists and table cells that assistive technology reads instead of the visual layout. A PDF that looks correct and has no tree is unreadable to a screen reader.
- PDF/UA-1Not produced by this API
ISO 14289-1: the standard that says a PDF is usable by assistive technology, which in practice means it carries a complete and correct structure tree.
- Tagged PDFNot produced by this API
A tagged PDF carries a second, invisible copy of itself: a tree of headings, paragraphs, lists and cells that says what the content is, rather than where the ink goes.
- Reading orderNot produced by this API
The sequence a screen reader speaks the document in, which comes from the order of elements in the structure tree and not from where anything sits on the page.
- Alt text on imagesNot produced by this API
A text description attached to a figure structure element, which is what a screen reader speaks in place of an image it cannot see.
- Document languageNot produced by this API
A language tag in the catalogue that tells a screen reader which voice and pronunciation rules to use for the document, and per-element tags for passages that differ.
- The logical structure treeNot produced by this API
The tree of typed elements, Document at the root and paragraphs, lists, tables and figures below it, that describes what the document is made of.
- Table header taggingNot produced by this API
Marking which cells are headers and which data cells they govern, so a screen reader can announce "Quantity, 4" instead of reading a grid of bare numbers.
- Heading levelsNot produced by this API
The /H1 to /H6 structure elements that give a document an outline, which is how a screen reader user skims a fifty page report without reading it.
- Artifacts and real contentNot produced by this API
The distinction between content that belongs in the reading order and page furniture that does not, marked in the content stream so a screen reader can skip the furniture.
Prepress and commercial print
PDF/X is a handover format. It exists so a printer can accept a file from a designer without a phone call, which means every ambiguity that would need a phone call is banned.
- PDF/X-1aNot produced by this API
The blind exchange standard for offset printing: everything is CMYK or a named spot colour, nothing is transparent, and the file carries enough information that the printer never has to ask you a question.
- PDF/X-3Not produced by this API
The same handover discipline as X-1a with one rule relaxed: device independent colour is allowed, so ICC tagged RGB and Lab content can stay in the file and be converted by the printer's own colour management.
- PDF/X-4Not produced by this API
The current print exchange standard, based on PDF 1.6, which keeps transparency and layers live in the file and lets the printer's own engine flatten them at the last possible moment.
- CMYK and spot colour in a PDFNot produced by this API
Print uses inks, the web uses light, and there is no CSS syntax that expresses either a CMYK ink mixture or a named separation, so the gap has to be closed somewhere other than the stylesheet.
- Bleed, trim and media boxesNot produced by this API
A printed page has at least three rectangles: the sheet, the finished size after cutting, and the slightly larger area artwork must fill so that a cut a millimetre off does not leave a white sliver.
- Overprint and transparencyNot produced by this API
Two different ways of putting one thing on top of another: overprint is an ink instruction that a screen mostly ignores, transparency is a rendering model that older print standards ban outright, and confusing them produces the classic disappearing white text.
Metadata, versions and file structure
The parts of a PDF that say what it is rather than what it shows: the version header, the metadata packets, the information dictionary, and how the objects are laid out in the file.
- XMP metadataPartly, and the page says how far
An XML packet in the document catalogue carrying the file's own account of what it is: title, author, dates, and any conformance it claims.
- The document information dictionaryNot produced by this API
The older metadata mechanism: a dictionary in the trailer holding /Title, /Author, /Subject, /Keywords and the creation and modification dates.
- PDF version numbersPartly, and the page says how far
The version in the file header and optionally in the catalogue, which says which features a reader must understand to open the file correctly.
- PDF 2.0Not produced by this API
ISO 32000-2, the first version of PDF published by ISO without an Adobe specification behind it, and the base for PDF/A-4.
- Linearized PDFA step after rendering
A file laid out so a reader can display page one before the rest has arrived, which is what "fast web view" means in a viewer's properties panel.
Signatures, encryption and attachments
Signing, encrypting and attaching. These are the features that decide whether a document can be trusted, opened, or made to carry a machine-readable payload alongside the page.
- Digital signature fieldsA step after rendering
A form field holding a cryptographic signature over the file, which proves who signed it and that nothing has changed since.
- Certification signatureA step after rendering
The first signature on a document, which certifies the whole thing and declares what, if anything, anyone is allowed to change afterwards.
- PAdES signature levelsA step after rendering
The four European profiles for PDF signatures, each adding what the one below it needs to still be verifiable years later.
- Encryption and conformancePartly, and the page says how far
Why a password-protected file can never be PDF/A or PDF/UA, and what the password option here actually gives you.
- Embedded files in PDF/A-3Not produced by this API
The mechanism behind hybrid invoices: a machine-readable XML payload carried inside an archivable PDF, so one file serves both the person and the system.
- AcroForm fieldsNot produced by this API
Interactive form fields inside a PDF, and why an HTML input rendered to PDF is a picture of a field rather than a field.