Colour and ink / How the ink lands
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.
What actually happens
Black ink alone, laid on white paper at small sizes, is a clean crisp black. Add cyan, magenta and yellow underneath it and you get a denser, deeper black that is visibly darker across a large area. That is the whole reason rich black exists: single black over a big panel looks washed out and slightly grey next to a photograph. The problem is that a rich black is four inks that must land in exactly the same place, and at 9 point text they do not. The plates shift by a fraction of a millimetre, and every letter acquires a coloured fringe. So the rule is not that one black is better: it is that large solid areas want rich black and small text wants black alone, and a stylesheet that uses one value everywhere gets one of the two wrong.
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.
- Use a single black for body text, rules, and anything below about 24 point. Registration error is invisible on a panel and obvious on a letterform.
- Use a richer black for large solid areas, display type and full-bleed panels, where the extra density is visible and the registration risk is not.
- Say which you mean in the markup rather than relying on the converter to guess. A converter turning your RGB black into four-colour black everywhere is a common and expensive default.
- Never set body text to a near-black such as #111111 expecting it to convert to black ink. Anything that is not pure black converts to a mixture, which is the fringing case again.
- Keep one black value for text across the whole document. Two slightly different near-blacks in the same document print as two visibly different greys.
- Where a document is going to a press, say in the handover which blacks are which. It is a two line note that saves a reprint.
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.
:root {
/* Text black: pure, so a converter maps it to black ink alone and
the letterforms cannot acquire a registration fringe. */
--ink-text: #000000;
/* Panel black: used only on large solid areas, where the extra
density reads and a fraction of a millimetre of shift does not. */
--ink-panel: #0a0a0a;
}
body { color: var(--ink-text); }
/* small type: single black, always */
p, td, th, li, .footnote { color: var(--ink-text); }
/* large solid areas: the denser value */
.cover-panel { background: var(--ink-panel); }
.display-heading { color: var(--ink-panel); font-size: 42pt; }
/* The mistake this avoids: a near-black body colour. #111 is not black,
it is a mixture, and at 9pt a mixture fringes.
p { color: #111; } <-- not this */What people do instead
Setting body text to a soft near-black like #222222 because pure black looks harsh on a screen. On a screen it does. On paper it is a four-ink grey at 9 point, and every letter has a coloured edge. Screen comfort and print legibility want opposite things here, and the document is going on paper.
How to find out rather than assume
Print a page on the real device and look at the body text with a loupe or a phone camera at maximum zoom. Clean black edges mean single black. Any colour visible at the edge of a letter means the black converted to a mixture, and the fix is in the CSS value, not at the printer.
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.
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.
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.
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.
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.