Prepress and commercial print / PDF/X-4
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.
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 cannot produce a PDF/X file of any part, and X-4 is no exception: there is no colour conversion, no output intent, no page box control and no way to write the Trapped entry. The interesting difference from the other two X pages is what you no longer have to worry about in your source. Transparency is legal here, so the rgba() colours, shadows and blend modes in your stylesheet are not automatic failures, and the gap between a rendered file and an X-4 file narrows to colour, boxes and metadata, which are exactly the things a converter can supply.
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.
- Live transparency permitted, which removes the flattening step that made X-1a and X-3 files fragile and enormous.
- Optional content groups permitted, so a document with language layers or with a varnish layer can be handed over intact.
- ICC based colour permitted alongside CMYK and spot, as in X-3.
- All fonts embedded, a TrimBox or ArtBox on every page, and the Trapped entry set to True or False.
- One output intent with the profile embedded, or in the X-4p variant an external profile referenced by name where both parties have agreed on it.
- A RIP at the other end that actually supports it. This is the practical requirement and it is not in the standard.
Who asks for this
Modern print workflows and most digital presses. It is what a designer's export dialogue defaults to for good reason: flattening transparency early produces enormous files, visible seams where the flattener split objects, and text converted to outlines that then fails a Unicode check. X-4 avoids all three by not flattening.
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.
# Ghostscript can write PDF/X output. PDFX_def.ps names the output intent
# profile and the condition, in the same shape as the PDF/A recipe.
gs -dPDFX -dBATCH -dNOPAUSE -dNOOUTERSAVE \
-sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK \
-dPDFSETTINGS=/prepress \
-sOutputFile=brochure-x4.pdf \
PDFX_def.ps brochure.pdf
# Then preflight the result rather than trusting the exit code. Ghostscript
# will happily write a file that a printer's profile rejects, and the report
# from a preflight tool names the object, which is what you need.What to do about it
Render at the right physical size with bleed included, then convert with a preflight tool targeting PDF/X-4, which will assign or convert colour, embed the intent, set the boxes from your page geometry and write the Trapped key. Ghostscript can produce PDF/X output with a PDFX_def.ps in the same shape as the PDF/A recipe, though a dedicated preflight tool gives you a report rather than a silent result.
How to check a file rather than assume
Acrobat preflight with a PDF/X-4 profile, or the printer's own preflight if they will share it, which is better because it is the check that decides. Inspect the page boxes as well: a file that passes conformance with a TrimBox equal to the MediaBox has no bleed, and that is a production failure rather than a validation one.
The mistake people make here
Sending X-4 to a shop whose RIP predates it. The file is correct, the standard is current, and the job still comes back wrong because their equipment flattens it in a way nobody proofed. Ask which X part their preflight profile targets rather than assuming the newest is safest.
Frequently asked
Does this API produce PDF/X-4?
Not produced by this API. The API cannot produce a PDF/X file of any part, and X-4 is no exception: there is no colour conversion, no output intent, no page box control and no way to write the Trapped entry. The interesting difference from the other two X pages is what you no longer have to worry about in your source. Transparency is legal here, so the rgba() colours, shadows and blend modes in your stylesheet are not automatic failures, and the gap between a rendered file and an X-4 file narrows to colour, boxes and metadata, which are exactly the things a converter can supply.
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.
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.
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.
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.
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.