PDFPipe

Colour and ink / What happens when the colour is converted

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.

What actually happens

There is no such thing as a lighter ink. A tint is the same ink printed as small dots with paper showing between them, and your eye averages the two into a lighter tone. What happens on paper is that each dot spreads slightly as the ink is absorbed, so it covers more area than it was meant to, and the averaged tone comes out darker than the percentage says. The effect is proportionally largest in the light tints, which is exactly where documents use them: a 10 percent tint behind a table row can print closer to 20, and the calm background you designed becomes a grey band that competes with the text on it. The amount depends on the paper and the press, which is why the number comes from the printer rather than from a rule of thumb.

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.

  • Specify light tints lighter than you want them to look, and confirm the amount of gain with the printer rather than guessing at it.
  • Avoid tints below about 5 percent. They are close to the point where the dots become individually visible or disappear entirely, and which of those happens is not yours to decide.
  • Prefer a rule to a tint for separating table rows. A rule is a solid mark that prints as specified; a tint is an average that shifts.
  • Where a tint is carrying meaning, keep the steps between levels wide. Three tints at 10, 15 and 20 percent will not be three distinguishable tones on paper.
  • Remember uncoated paper absorbs more and gains more than coated. The same tint on two stocks is two different greys.
  • On an office laser this behaves differently again, because toner does not absorb, so a tint tuned for a press is not tuned for the copier down the hall.

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
/* Tints specified lighter than the intended result, because the
   printed dots spread and the averaged tone darkens.
   The actual amount is a property of the paper and press: get it
   from the printer rather than assuming these values. */

:root {
  --tint-row: #f4f2ec;    /* a very light band, expected to print darker */
  --tint-panel: #e8e5dc;
}

/* Preferred for table rows: a rule prints as specified, a tint averages. */
.table tbody tr td { border-bottom: 0.4pt solid #ccc; }

/* If a tint is unavoidable, keep the steps between levels wide enough
   that gain cannot collapse two of them into one. */
.level-1 { background: #f4f2ec; }
.level-2 { background: #ded9cc; }   /* not 5% away: far enough to survive */
.level-3 { background: #b8b0a0; }

What people do instead

Using a very light tint to make a table calmer and finding the printed version has a heavy grey band under every other row. The tint that looked like nothing on screen is the one where gain is proportionally worst, and the fix people reach for, going lighter still, takes it into the range where it prints inconsistently instead.

How to find out rather than assume

Print a strip of your tints at actual size on the real stock and look at it next to the screen. Then photocopy it. Any two levels you can no longer separate on either are too close, and any tint that has become a visible band was specified too dark.

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.