Prepress and commercial print / Overprint and transparency
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.
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 overprint control and CSS has no syntax for it, so nothing rendered here carries an overprint flag and the disappearing white text failure cannot originate in the render. Transparency is a different story: CSS produces it constantly, through opacity, rgba() and hsla() colours, box shadows, and any blend mode. That transparency is legal under PDF/A-2 and later and under PDF/X-4, and it is forbidden under PDF/A-1, PDF/X-1a and PDF/X-3, which is why the same document can be conformant against one standard and fail another without a byte changing.
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.
- Overprint expressed in a graphics state as the OP and op flags, with the overprint mode deciding whether a zero component leaves the underlying ink alone or knocks it out.
- Transparency expressed as an alpha value or a blend mode on a transparency group, which is a PDF 1.4 feature and forbidden by PDF/A-1, PDF/X-1a and PDF/X-3.
- White objects never set to overprint, because white in CMYK is the absence of all four inks and overprinting nothing prints nothing.
- Flattening applied once, late, by a tool that can be proofed, rather than accidentally by an export setting nobody chose.
- An awareness that a screen preview lies about overprint unless overprint preview is switched on, which it is not by default in most readers.
- Blend modes checked individually, since several of them change appearance when flattened against a CMYK background rather than an RGB one.
Who asks for this
Prepress operators, and everyone else only after the job has come back wrong. The failure is memorable: a white logo on a dark panel prints as a dark panel with nothing on it, because somewhere in the chain the white object acquired an overprint flag and white ink does not exist.
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.
<style>
/* Aiming at PDF/A-1 or PDF/X-1a? Every one of these puts transparency in the
file and the file then fails on a clause that does not mention shadows. */
.card--fails-part-1 {
background: rgba(15, 47, 74, 0.08); /* alpha, so a transparency group */
box-shadow: 0 2px 6px rgba(0, 0, 0, 0.2);
opacity: 0.9;
mix-blend-mode: multiply;
}
/* The same visual weight with no alpha anywhere. Pre-mix the tint against the
known page colour and use a border where the shadow was carrying a boundary. */
.card--safe {
background: #eef1f5; /* the 8 percent tint, already mixed */
border: 1px solid #c9d2dc;
border-left: 3px solid #0f2f4a;
}
</style>What to do about it
Decide which standard you are aiming at before you style the document, because that decision is what makes a shadow either fine or fatal. If the target permits transparency, use it freely. If it does not, replace opacity with pre-mixed solid colours, replace shadows with rules or borders, and avoid blend modes entirely, since a document with no transparency in it never has to be flattened and therefore cannot be flattened wrongly.
How to check a file rather than assume
Turn on overprint preview in Acrobat and look at the document again. Anything that disappears or changes was relying on a preview that was lying to you. Acrobat's output preview will also list the transparent objects on a page, which is quicker than hunting through a stylesheet for the one rgba() that failed a PDF/A-1 check.
The mistake people make here
Reaching for a subtle drop shadow on a document destined for PDF/A-1. It is one line of CSS, it looks like styling rather than structure, and it puts a transparency group into the file that fails validation on a clause with no obvious connection to shadows. If the target is part 1, treat box-shadow, opacity and rgba() as unavailable rather than as things to clean up later.
Frequently asked
Does this API produce Overprint and transparency?
Not produced by this API. The API has no overprint control and CSS has no syntax for it, so nothing rendered here carries an overprint flag and the disappearing white text failure cannot originate in the render. Transparency is a different story: CSS produces it constantly, through opacity, rgba() and hsla() colours, box shadows, and any blend mode. That transparency is legal under PDF/A-2 and later and under PDF/X-4, and it is forbidden under PDF/A-1, PDF/X-1a and PDF/X-3, which is why the same document can be conformant against one standard and fail another without a byte changing.
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-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.
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.
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.
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.