Too Light for Print

If you thought you had a reasonable amount of control over the color of your typography using CSS, you thought wrong. One of the absolute flakiest, inconsistent issues you will ever encounter in CSS is trying to get accurate color applied to your fonts. In all major browsers, certain color values are modified if the browser deems them to be “too light for print” and it will render a color that it thinks will be better suited for your output on a printed page.

Now the reason why the browser vendors have made this assumption is fairly obvious: printing light text on what is almost always white paper is largely unreadable, and it is sadly very rare that web authors will take the time to style their pages for print using an alternate print style sheet (if they ever style it for print at all). Furthermore, printing in pure black, devoid of any complex color mixing, can make printing much faster, because the printer doesn’t have to mix in any red, green, or blue ink and can focus on getting the task done. But what is maddening to the designer trying to achieve accurate color representation in print from their web pages is that all of the major browsers assume that they are smarter than you, and recolor the text based on their own inconsistent algorithms. If you wanted a string of text to appear very light gray in Firefox, too bad. You are getting black whether you like it or not. Let’s look at some of the problems you might encounter.

In Safari 3 (on the left-side), gray colors print fine up until rgb(107, 107, 107). After that point there will be a strange conversion to a light gray shade, arguably the lightest gray you can get in text on Safari, between rgb(108, 108, 108) and rgb(127, 127, 127). At rgb(128, 128, 128), the text color then jumps to black and as you ascend the values toward an expected white color, Safari yields a progressive amount of additional lightness to the text until it finally winds up at around rgb(171, 171, 171), where it should be 255 for all values.

This problem also occurs in the red, green, and blue colorspaces. If we fix red at 127, about halfway between the minimum value of 0 and the maximum value of 255, we get a dead zone between rgb(127, 100, 100) and rgb(127, 127, 127). The same ratios happen starting at rgb(100, 127, 100) and at rgb(100, 100, 127). Finally, Safari renders rgb(0, 255, 255), rgb(255, 0, 255) and rgb(255, 255, 0) inconsistently from their adjacent color values.

Gecko browsers such as Firefox (before version 3), Camino, and Flock print the entire gray space in black. You cannot specify a light gray such as rgb(127, 127, 127) or anything else. It will always default to pure black whether you like it or not. If you fix a color bucket at 0, you will get semi-accurate color for the rest of the gamut, but the other color combinations will trend toward black text the lighter it gets. The exception here is Firefox 3, which will print your color exactly as specified. As of this writing, Firefox 3 is the only browser I’ve tested that gets the color matching between screen and print relatively correct.

Interestingly, the marker (the little bullet to the left of each list item) will display the correct color value in print for Firefox and Safari, even though the text itself won’t match! So at least here you can use the markers to see what the color was supposed to be…

In Opera 9, gray shades render accurately up until rgb(185, 185, 185), and then higher values default to black. In the points tested, the same conversion to black happens in various other colorspaces at different points. For instance, color values higher than rgb(127, 211, 211), rgb(255, 156, 156), rgb(87, 255, 255), rgb(209, 209, 0), rgb(193, 193, 127) and rgb(177, 177, 255) will stop rendering their expected colors and just print black instead, thank you very much.

IE7 never gets any lighter than rgb(108, 104, 102) for grayscale, and the rest of the color spaces don’t seem to allow anything lighter than a midrange hue equivalent in any given color range.

Since all the major browsers have made the assumption that you’ve neglected to pay appropriate attention to your print output with regard to color and contrast, you have to live with that and deal with some fairly tricky constraints. One argument is to give in and just go for all black text on all white paper, and certainly there’s an argument for that in terms of readability and performance. But for that argument we should all be designing white web pages with black text too and just toss out all our assumptions about color theory, design, and inspiration. We know clearly that the primary function and goal for printing a page is for reading purposes, but what if you wanted to do something else. Something more artistic, perhaps? For truly accurate printing from the Web, you may want to stick with PDF or similar output. But there’s still plenty we can do with print using plain-old HTML and CSS, and it can be an interesting academic exercise to try to design within these constraints. Think of it as a challenge that will make your professional world that much more interesting!