PDFPipe

Colour and ink / What happens when the colour is converted

Designing a document that will be printed in one or two colours

A document produced with fewer inks than four, either to control cost or because the process only offers one, and what that does to a design built in full colour.

What actually happens

A one or two colour job is not a full colour design with the colour removed. Every distinction in it has to be carried by the inks available plus tints of them, which means the whole hierarchy has to be built from tone and weight rather than hue. Photographs are the sharpest constraint: a colour photograph reproduced in a single ink is a monochrome image, and reproduced in two inks is a duotone, which is a deliberate treatment rather than an automatic conversion. A design that assumes four inks and is then produced in one does not degrade gracefully, it collapses, because everything that was distinguished by hue is now the same.

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 the ink count before the design rather than after. It is a constraint that shapes every other decision and it cannot be applied at the end.
  • Build the hierarchy from weight, size and tone. With one ink those are the only variables you have, and they are enough if they are used deliberately.
  • Treat photographs as a separate decision. A colour image in a one-colour job needs converting deliberately, with attention to its contrast, not passing through a driver.
  • Use tints of the ink you have rather than reaching for a second ink. A single ink at four well-separated tint levels gives more usable distinctions than most designs need.
  • Where there are two inks, make one of them do the structural work and the other the emphasis, rather than treating them as two equal colours.
  • None of this is expressible as an option on a render. The document is produced in RGB and the ink decision happens downstream, so what you control is that the design does not depend on hue.

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.

css
/* A single-ink system: one hue, four well-separated tone steps, and
   hierarchy carried by weight and size rather than by colour. */

:root {
  --ink: #1d1812;
  --ink-70: #56514a;
  --ink-40: #9a958e;
  --ink-12: #e4e1db;
}

body { color: var(--ink); }
.muted { color: var(--ink-70); }
.faint { color: var(--ink-40); }
.panel { background: var(--ink-12); }

/* Emphasis without a second hue. */
h2 { font-size: 16pt; font-weight: 700; color: var(--ink); }
h3 { font-size: 11pt; font-weight: 700; color: var(--ink); }
.lede { font-size: 12pt; color: var(--ink-70); }

/* Images: convert deliberately rather than letting a driver do it. */
.plate img { filter: grayscale(1) contrast(1.05); }

What people do instead

Designing in full colour and asking for it to be produced in one ink at the end. Everything distinguished by hue merges, the photographs go muddy, and the result is not a cheaper version of the design, it is a broken one. The ink count is an input to the design.

How to find out rather than assume

Set the whole document in one hue and its tints and read it. If the hierarchy still works and the images still carry their content, it will survive a single-ink production. If you have to reintroduce a colour to make something clear, that thing needs a different treatment.

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.

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.