Prepress and commercial print / CMYK and spot colour in a PDF
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.
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. There is no colour conversion in this API and no way to express a separation. CSS has no CMYK notation and no spot colour syntax, so everything reaches the file as device RGB, and a Pantone name written into a stylesheet as a comment or a custom property is documentation for a human rather than a colourant in the output. Nothing you can set changes this. What is worth doing in the source is choosing RGB values that are already close to their printable equivalents, so the later conversion moves them as little as possible.
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.
- CMYK content stored as a DeviceCMYK colour space, or as an ICC based space with four components, so each value is an ink coverage rather than a screen colour.
- A spot colour stored as a Separation colour space naming the colourant, with a tint transform giving the alternate space so a reader can approximate it on screen.
- Total area coverage kept within what the press and paper allow, commonly around 300 percent for coated stock, because exceeding it causes ink not to dry.
- Rich black used deliberately for large solid areas, and single channel black used for small text, since four ink black text shows any misregistration immediately.
- An output intent describing the printing condition, without which the numbers have no defined meaning.
- Overprint set explicitly where a spot colour must sit on top of another ink rather than knocking a hole in it.
Who asks for this
Anyone whose document is going onto paper through a commercial press rather than an office printer. It arrives as a brand requirement (the corporate colour is a specific Pantone), as a cost requirement (a two colour job cannot contain a four colour build), or as a preflight rejection.
What to do about it
Convert on the finished file, against the profile for the actual printing condition, and treat brand colours as a separate problem from the rest of the page. Get the specified CMYK build for the brand colour from whoever owns the brand and have the conversion tool map it exactly, rather than letting a generic profile decide what your logo looks like. For true spot colours, the separation has to be created by a prepress tool or by the printer, and that is normally a conversation rather than a pipeline step.
How to check a file rather than assume
Acrobat's output preview shows the separations present in a file and the total area coverage under the cursor, which answers both of the questions that matter. For a quick check without Acrobat, Ghostscript's tiffsep device will separate a file into plates, and seeing four plates where you expected two is a fast way to catch a stray RGB element.
The mistake people make here
Setting body text to a CSS colour that converts to four ink black. A page of small text built from all four separations looks slightly soft and shows every registration error the press makes, while the same text in single channel black is crisp. The fix belongs in the conversion settings, where black text can be preserved as K only, but you have to ask for it.
Frequently asked
Does this API produce CMYK and spot colour in a PDF?
Not produced by this API. There is no colour conversion in this API and no way to express a separation. CSS has no CMYK notation and no spot colour syntax, so everything reaches the file as device RGB, and a Pantone name written into a stylesheet as a comment or a custom property is documentation for a human rather than a colourant in the output. Nothing you can set changes this. What is worth doing in the source is choosing RGB values that are already close to their printable equivalents, so the later conversion moves them as little as possible.
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/X-1a: the CMYK-only handover format for commercial print
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.
Overprint and transparency, and the white text that vanishes
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.
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.
PDF/X-3: managed colour instead of CMYK only
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-4: live transparency in a print handover file
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.
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.