The woes of CSS color in print typography

Smoking Room/Prayer Room

As I was working through some documentation on styling CSS for print recently, I came across an oddity. Colors that I was specifying in my print styles were not getting represented properly at print time. Specify a nice shade of gray for some text? Maybe want to ghost print something very lightly on the printed page. No – not in Firefox. In fact, any shade of gray comes out as black in Gecko browsers. This behavior is only slightly more intelligent in Safari and IE7, but in all cases the user agent makes an assumption about what color of text constitutes being “too light” and then defaults to a darker shade of pale that is handled inconsistently across the various browsers. Printing font colors appears to be a messy situation.

Now the reason why the browser vendors have made this assumption is clear: Printing light text on what is almost always white paper is largely unreadable. 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 the designer, and recolor the text based on their own inconsistent algorithms. Actually, that may be assuming a bit much on the part of the browsers – sometimes the results defy logic.

To investigate further, I created a testing page. This page runs through some of the various color gamuts and creates a list entry for a number of color variations. The results are surprising… Here are some findings:

  • Safari 3: Between rgb(0,0,0) and rgb(107,107,107), things appear fine. But then there is a breakdown between rgb(108,108,108) and rgb(127,127,127) where the text will randomly jump to a light gray – equivalent of rgb(199,199,199). For lack of a better term, I call this area “The Dead Zone,” and we will see it again soon. At rgb(128,128,128), the text color then jumps to black and as you ascend the values towards 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.

    The Dead Zone also occurs in the red, green, and blue colorspaces. If you 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). 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, Camino, and Flock print the entire gray space in black. (Exception: Firefox 3 will actually print the color exactly right – see below.) 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 towards black text the lighter it gets.

  • 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 after 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).

  • 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 to around 110 for any given value.

  • One last thing about Gecko browsers: The marker (the little bullet to the left of each list item) will display the correct color value in print, even though the text itself won’t match! Underlines/Overlines/strikethrough will match whatever color the text is though. So at least here you can see what the color was supposed to be…

  • The exception as mentioned above is Firefox 3. Firefox 3 has been tested to print the colors exactly as you see them on screen, and is the only browser thus far that works this way in a predictable manner.

The conclusion I draw from all of this is that color in CSS print typography is woefully inconsistent, and I do recommend defaulting to black text in most cases simply because it is so problematic to predict what color you will actually wind up with in print. If you need color, go with a darker shade and test your print output in the four major modern browsers (IE, Safari, Firefox, Opera) to see what you can get away with.

Please feel free to try the test suite for yourself and let me know your findings in the comments or via a pingback.

14 thoughts on “The woes of CSS color in print typography”

  1. Interesting. I wonder if that’s a “feature” or a bug in the rendering engines.

    Just curious as to whether you tried setting the color values any other way (hex for example), and if the results were similar? I’d guess yes….

  2. Wow, that certainly throws a serious wrench into the plans of anyone trying to do anything interesting for print designs via a web browser UA. This is one of those times where I think it’s actually more helpful to give designers enough rope to hang themselves with instead of trying to “protect” them from themselves.

  3. I too discovered this the hard way. (Spent at least an hour testing all kinds of stuff before I realized that it was a browser specific issue.)

    Does anyone know if there is a way to disable/modify this behavior in the browser? I’m not asking about messing with clients browsers who visit our site – what I’m asking is if there is a way I can edit my own personal browser so that I can print lighter text. IE is what I’m using for this particular application.

    I know that FF has about:config, but looking through it I didn’t see anything.

    Anyone have any ideas on this?

  4. BTW – Did you know that Chrome DOES print very light text?

    I just did your test page with Chrome (even printed all the grays) and they all printed fine, even down to 255,255,255 being white.

    But in FF they are all black, in IE they go to around the 108 area as you say.

  5. Ha ha, I was wondering why you didn’t mention Chrome in your original post. I only just now noticed that it was from 2008.

    So, I am wondering if there is any way to modify my browser to override this “feature”?

    Our issue is that we must print from IE for certain things at work and we need to be able to print lighter text.

  6. > “Printers don’t use red, green, or blue ink, but cyan, magenta and yellow.”

    No. But, unless they print through a PostScript RIP, they generally only take RGB values as input. Print CMYK to a non-PS inkjet and the first thing the driver is going to do is convert your CMYK to RGB. Sometimes with questionable results.

    (For that matter, even printing generic CMYK to a CMYK-capable device isn’t as simple as just mapping those values directly to ink colors. But that’s getting into the weeds of color management and even more beside the original point.)

Leave a Reply

Your email address will not be published. Required fields are marked *