Colour and ink / How the ink lands
Total ink coverage, and the panel that will not dry
The sum of all the ink percentages laid in one place, which has a physical ceiling that a colour chosen on a screen knows nothing about.
What actually happens
On a press each of the four inks is laid as a percentage, and their sum in any one spot is the total coverage. There is a limit to how much wet ink a sheet can carry: past it the ink does not dry properly, it sets off onto the back of the next sheet in the stack, and the paper cockles. A colour picked on a screen has no coverage figure attached to it, and a dark saturated colour, or a rich black built by adding all four inks at full strength, can convert to a total far above what the paper will take. This is one of the few production problems whose symptom appears after printing rather than on the printed sheet, which is why it is discovered late and expensively.
Where this API stands on colour
This API renders HTML to PDF, and the colour in the output is the colour in your CSS, which is RGB. There is no colour-space option, no CMYK mode, no ICC embedding, no ink-limit control and no greyscale conversion. Two options touch colour at all and neither changes a colour value: print_background, which is on by default here and off by default in most renderers, decides whether backgrounds and background images are painted at all, and media decides whether your print stylesheet applies. Anything that converts this document into inks happens after the render, in a tool you choose, and that is where the decisions on this page are enforced.
The decisions that avoid it
Reasons rather than a description of the code. Each of these is a choice with a wrong answer, and the wrong answer usually looks correct on a screen.
- Ask the printer for the coverage limit for the specific paper and press before designing anything with large dark areas. It varies by both, and it is a number they will give you immediately.
- Keep large solid dark areas out of the design where you can, rather than trying to tune them down to a limit you were told about afterwards.
- Build a rich black deliberately rather than letting a converter build one, because the converter's version is usually the one that exceeds the limit.
- Watch for dark colours stacked behind other dark colours. Coverage is a sum over everything in one place, so a dark panel behind a dark photograph is the case that goes over.
- There is nothing in CSS that expresses ink coverage. It is a property of the converted file, so it is checked in the converted file and not in the stylesheet.
- On an office laser this does not apply. Toner is fused rather than absorbed, so a coverage problem is a press problem and worrying about it for an internal document is wasted effort.
In the stylesheet
Where the decision is expressible in CSS, this is what it looks like. Where it is not, the snippet says so rather than inventing a property.
/* There is no CSS for ink coverage: it is a property of a converted
file, not of a stylesheet. What CSS can do is keep the design out
of the region where it becomes a problem. */
:root {
/* A panel colour chosen to be dark without being a full four-ink
build. Confirm the converted coverage with the printer rather
than assuming any RGB value is safe. */
--panel-dark: #232019;
}
.cover-panel {
background: var(--panel-dark);
print-color-adjust: exact;
-webkit-print-color-adjust: exact;
}
/* The case to avoid: a dark panel under a dark image. Coverage is a
sum over everything in one place. */
.cover-panel .photo { mix-blend-mode: normal; }What people do instead
Treating this as a design problem and trying to solve it in the stylesheet. Coverage is a property of the converted file: the same RGB value converts to different totals under different profiles, so a value that was fine on the last job is not a value you can carry forward. The number comes from the printer and the check happens on the converted file.
How to find out rather than assume
There is nothing to check in the browser. Send the converted file to the printer and ask them to run a coverage check, or run one yourself in a preflight tool. It reports the highest total in the document and where it is, which is the two things you need.
Frequently asked
Can I ask the API for CMYK output?
No. There is no colour-space option on the render, and the document comes out in RGB. Converting to CMYK is a downstream step: a preflight tool or a converter rewrites the colour against a profile you choose, and that is also where an output intent and an ink-coverage check belong. Convert after rendering rather than trying to reach the conversion from a stylesheet.
Will my backgrounds and tints print?
From this API they are painted into the document by default, because print_background defaults to true here rather than to false. What happens afterwards is the reader's print settings, and a viewer told not to print backgrounds will still drop them. That is why every page in this cluster treats a background as an enhancement rather than as the thing carrying the meaning.
Does any of this apply to a document that is only ever read on screen?
Very little of it. Dot gain, ink coverage, registration and paper are properties of a physical process. If the document is genuinely never printed, photocopied or faxed, most of this cluster is not your problem. The reason it is worth reading anyway is that people are consistently wrong about which of their documents get printed.
Related colour and ink topics
The topics that cause each other, then the rest of the same group.
Rich black against 100% K, and why body text uses one of them
Two different blacks that look identical on screen and behave completely differently on paper: one made from black ink alone, one made by adding the other three inks underneath it.
The same PDF on an office laser and on a commercial press
Two output devices with different resolutions, different colour behaviour and different physical limits, producing two different objects from one file.
Why a 10% tint prints darker than it looks on screen
A percentage screen of a colour, which is printed as a pattern of dots rather than a lighter ink, and comes out darker than specified.
White type on a coloured panel that stays readable on paper
Text knocked out of a solid colour so the paper shows through it, which is the most fragile way to set type in print and the most common on screen.
Thin rules that vanish or thicken between screen and paper
Rules and borders specified below the width the output device can actually draw, which come out either heavier than asked or not at all.
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 colour and ink topic
The full list, grouped by whether it happens in the ink, in a conversion, or at the device.
Everything on this page is decided in your stylesheet or at the printer. Render the document, then put it on the paper it will actually be printed on.