Prepress and commercial print / PDF/X-1a
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.
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 CMYK path. Colour is expressed in CSS and lands in the file as device RGB, so a printer's preflight fails it on colour space before it examines anything else, and there is no option that changes this. Two things on your side still matter. Avoid transparency in the source, because a flattening step later will change the rendering and you would rather see that now than on a proof. And do not put a spot colour name into CSS expecting it to survive: there is no CSS syntax for a separation, so a Pantone reference in your stylesheet is a comment.
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.
- All colour as CMYK or as named spot colours. RGB is not permitted anywhere, including inside placed images and inside vector artwork.
- No live transparency. Anything transparent must be flattened before the file is written, because the standard is based on PDF 1.3 and 1.4 behaviour.
- All fonts embedded, with no exceptions for the standard faces.
- Exactly one output intent naming the printing condition, with the ICC profile embedded.
- A TrimBox or an ArtBox on every page, so the finished size is stated rather than inferred from where the marks are.
- A Trapped entry in the document information dictionary set to True or False, never Unknown, because the printer needs to know whether trapping has already been applied.
Who asks for this
Commercial printers, and specifically the ones running conventional offset work through an older prepress workflow. If a print quote arrives with a PDF/X-1a:2001 requirement attached, it is usually because their preflight is configured for it and deviating means a phone call and a delay rather than a rejection.
What to do about it
Send the printer what you have and let them convert, or convert deliberately yourself with callas pdfToolbox, Acrobat preflight or a colour server, choosing the destination profile from the printing condition they specify. Doing it yourself is worth it only if you can proof the result, because RGB to CMYK conversion changes saturated colours visibly and finding that out at press is expensive. Either way the conversion happens after rendering, on the finished file.
How to check a file rather than assume
Acrobat preflight has PDF/X-1a profiles and reports each failure with the object that caused it, which is what you need to find one stray RGB image in a hundred page catalogue. callas and Enfocus tools do the same and are what most printers run. A file that opens and looks right tells you nothing here, because RGB looks fine on a screen by definition.
The mistake people make here
Converting RGB to CMYK without proofing the result and assuming the numbers are the whole story. A vivid RGB blue or green has no CMYK equivalent, so the conversion picks the nearest printable colour and the brand colour on the cover comes back noticeably duller. If the document has a brand palette, get the CMYK values from whoever owns the brand rather than letting a profile decide.
Frequently asked
Does this API produce PDF/X-1a?
Not produced by this API. The API has no CMYK path. Colour is expressed in CSS and lands in the file as device RGB, so a printer's preflight fails it on colour space before it examines anything else, and there is no option that changes this. Two things on your side still matter. Avoid transparency in the source, because a flattening step later will change the rendering and you would rather see that now than on a proof. And do not put a spot colour name into CSS expecting it to survive: there is no CSS syntax for a separation, so a Pantone reference in your stylesheet is a comment.
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-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.
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.
Bleed, trim and media boxes in a PDF built for printing
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 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.
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.