Archiving and long-term storage / Output intent and ICC profile
Output intent: the ICC profile an archival PDF has to carry
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.
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 output intent support: there is no option to embed an ICC profile and no colour management step in the render at all. Colour goes into the file the way CSS expressed it, as device RGB. That is exactly the situation the output intent requirement exists to correct, and it is why the API's own PDF/A warning names the embedded ICC profile as one of the two things still missing. Nothing in your markup changes this, because the profile is a file-level structure rather than page content.
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.
- An OutputIntents array on the catalogue containing at least one dictionary whose subtype names the standard: GTS_PDFA1 for PDF/A, GTS_PDFX for PDF/X.
- A DestOutputProfile entry pointing to an embedded ICC profile stream, not a name, not a path, and not a reference to a profile installed on the machine.
- An OutputConditionIdentifier naming the condition, conventionally a registered name such as sRGB IEC61966-2.1 for RGB work or FOGRA39 for European coated offset.
- Consistency with the content: an output intent describing a CMYK press does not make RGB page content legal under PDF/X, it only says what the device is.
- Exactly one output intent for PDF/X, because more than one makes the intended condition ambiguous and defeats the point.
- The profile embedded in full. This is the requirement that adds real weight to the file, roughly half a megabyte for a typical CMYK profile.
Who asks for this
Nobody asks for an output intent by name. It arrives as a validator failure on a file you thought was finished, because every part of PDF/A and every part of PDF/X requires one as soon as any device colour appears in the document, and device colour appears in almost every document.
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.
%% What the converter writes into the catalogue. You do not author this by
%% hand, but recognising it in a dump is how you tell a real intent from a
%% half-written one.
/OutputIntents [
<<
/Type /OutputIntent
/S /GTS_PDFA1
/OutputConditionIdentifier (sRGB IEC61966-2.1)
/Info (sRGB IEC61966-2.1)
/DestOutputProfile 12 0 R %% an embedded ICC stream, not a filename
>>
]What to do about it
Add it during conversion, which is the only place it can be added. Ghostscript takes a PDFA_def.ps that points at an ICC file and writes the intent for you, and preflight tools do the same from a named profile in their settings. Choose the profile by where the document is going: sRGB for something that will be read on screen and archived, a press profile such as FOGRA39 or GRACoL only if the document is genuinely going to a press that uses it.
How to check a file rather than assume
veraPDF reports the missing intent as a specific clause failure rather than a generic error, so it is unambiguous. To inspect what a file already has, dump the catalogue with qpdf and look at the OutputIntents array: if DestOutputProfile is absent while the rest of the dictionary is present, some tool wrote the shape of an output intent without embedding the profile, which passes a casual look and fails validation.
The mistake people make here
Embedding a CMYK press profile into a document that will only ever be read on a screen. It adds weight to every file, it tells a reader to simulate a printing condition that does not apply, and on a document full of vivid RGB accents it makes the colours visibly duller. Match the intent to the destination, not to whichever profile you found first.
Frequently asked
Does this API produce Output intent and ICC profile?
Not produced by this API. The API has no output intent support: there is no option to embed an ICC profile and no colour management step in the render at all. Colour goes into the file the way CSS expressed it, as device RGB. That is exactly the situation the output intent requirement exists to correct, and it is why the API's own PDF/A warning names the embedded ICC profile as one of the two things still missing. Nothing in your markup changes this, because the profile is a file-level structure rather than page content.
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.
CMYK and spot colour in a PDF, and why CSS cannot reach them
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.
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.
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-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.
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.