Colour and ink / What the output device does to 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.
What actually happens
An office laser fuses toner onto the sheet at a moderate resolution with a colour range set by the device and not by you. A press lays wet ink through screens at a much higher resolution, against a profile, on a stock somebody chose. The differences that matter for a document are practical: the laser cannot print to the edge and the press can, the laser's colour is approximately whatever the device decides and the press's is managed, fine detail survives on the press and rounds on the laser, and coverage limits apply to one and not the other. Designing for one and producing on the other is the source of most of the surprises in this cluster, and the decision of which you are designing for is usually made implicitly and never written down.
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.
- Decide which device the document is for and design for that one. A document that must work on both is designed for the laser, because it is the more constrained of the two.
- Assume an unprintable margin of several millimetres on any office device, and keep everything that matters inside it. There is no full bleed on a laser.
- Do not expect colour accuracy from an office device. If a brand colour has to be right, that is a press job with a profile, not a laser job with hope.
- Expect fine detail to round on a laser. Hairlines, small reversed type and close tint steps are press features.
- Ignore ink coverage for laser output and respect it for press output. Toner is fused rather than absorbed.
- Where the same document goes to both, produce one file and check it on the laser, because anything that works there works on the press and the reverse is not true.
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.
/* One file, designed against the more constrained device.
Nothing important inside the unprintable margin, no reliance on
colour accuracy, no hairlines below what a laser can resolve. */
@page {
size: A4;
/* Comfortably clear of the unprintable edge on office devices. */
margin: 15mm;
}
:root {
--rule: 0.5pt; /* resolvable on a laser */
--text: #000000; /* no colour accuracy required */
}
.frame {
/* If a border is wanted, keep it well inside the trim rather than
at the sheet edge, which a laser cannot reach. */
border: 1pt solid var(--text);
margin: 0;
}
/* Reserved for press output only, where full bleed exists. */
@media print and (min-resolution: 1200dpi) {
/* Treat this as documentation of intent rather than a reliable
switch: resolution media queries are not consistently supported.
The dependable route is a separate file for the press. */
}What people do instead
Proofing on the design studio's good printer and producing on the office device in the branch. The proof shows the press behaviour and the branch shows the laser behaviour, and the difference is discovered by whoever has to use the document rather than by whoever approved it.
How to find out rather than assume
Print the final file on the cheapest device it will ever meet, at its default settings, on the paper that device has loaded. That is the worst case and it is the one most copies will look like. Anything that fails there fails in the field.
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.
Designing a document that survives being photocopied and faxed
What a document has to be like to still work after it has been through a copier, a scanner or a fax, which is where most operational documents end up.
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.
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.
How the paper changes the colour that was in the file
The stock the document is printed on, which is the white in every light area and therefore part of every colour on the page.
resolution in paged output
The property involved here, with its real support status.
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.