Colour and ink / How the ink lands
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.
What actually happens
A device draws a line by marking whole dots, so a rule thinner than one dot has to be rounded to something. Different devices round differently. A high-resolution device draws a very thin line faithfully and it disappears into the paper. A low-resolution one rounds it up to a full dot and the line comes out heavier than the one beside it that was specified twice as thick. Both outcomes break a table, because a table's meaning is carried by the relative weight of its rules: a heavier header rule and lighter row rules stop being distinguishable when both round to the same dot. The other half of the problem is units. A rule specified in pixels is specified in a unit with no physical size, so the same stylesheet produces different physical line weights at different scales.
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 rules in points, not pixels. A point is a physical measurement and a pixel in a paged document is whatever the scale made it.
- Keep the thinnest rule at 0.25pt or above, and prefer 0.5pt for anything that must be reliably visible on an office device.
- Make the weight difference between two rules at least a factor of two. A 0.4pt rule next to a 0.5pt rule is one rule on most devices.
- Do not use a hairline keyword or a zero width and expect the thinnest possible line. What you get is device-dependent and you have given up the choice.
- Where a rule separates content rather than decorating it, give it enough weight to survive a photocopy, which is roughly 0.5pt and a real grey rather than a light one.
- Check the total: a table with a rule under every row at 0.5pt puts a surprising amount of ink on the page, and lightening the colour is usually better than thinning the line.
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.
.table {
/* Points, so the weight is a physical measurement rather than a
scale-dependent one. */
--rule-hair: 0.4pt; /* row separators */
--rule-body: 1pt; /* header and total, a clear factor of two apart */
}
.table td { border-bottom: var(--rule-hair) solid #bbb; }
.table thead th { border-bottom: var(--rule-body) solid #1d1812; }
.table tfoot td { border-top: var(--rule-body) solid #1d1812; }
/* Not this: pixels have no physical size in a paged document, and a
sub-dot width is rounded by the device rather than by you.
.table td { border-bottom: 1px solid #bbb; }
.table td { border-bottom: thin solid #bbb; } */What people do instead
Lightening a rule to make a dense table calmer by taking the width down rather than the colour up. Below about a quarter of a point the width stops being yours to choose, so the table looks calmer on screen and comes out on paper with every rule the same weight. Take the colour lighter and leave the width alone.
How to find out rather than assume
Print the table on the lowest-resolution device it will ever meet, which is usually an office laser rather than the press. The header rule and the row rules should still read as two different weights. If they do not, the difference between them was smaller than one dot.
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.
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.
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.
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.
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.
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.
mm, cm, in, pt 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.