I’ve been hearing recently about 16-bit printing and how, apparently, you can’t do it on Windows (for example on this thread). 16-bit (and more, but we’ll get to that in a moment) print support was added in Windows Vista and Windows Server 2008. At the same time we made that support available down level to Windows XP and Windows Server 2003 (down level is Microsoft-speak for previous versions of the platform).
This means that if you’re using supporting applications and devices on a version of Windows released in the last seven years, you can benefit from what’s generally called ‘16-bit printing’ . As some people like to say, that’s “goodness”.
That’s the high level description of the capabilities, but underneath lies a whole world of complexity. Since you’re here & reading this then it’s likely that you’re interested in that complexity so, with that in mind, now might be a good time to grab a mug of coffee/cup of tea/glass of water before we dive down into some interesting detail…
What is ‘16-bit printing’?
First, let’s define some terminology. I used the term 16-bit above because that’s how people typically talk about this stuff, but from the Windows perspective what we’re really talking about is extended color print support. For color representation in Windows there’s a number of concepts to consider:
Prior to the new print path (the XPS Print Path) introduced in Windows Vista, color printing support through the operating system was limited in two ways:
The XPS Print Path extended the support for color content in several significant areas:
Two other key technologies related to high quality color printing were introduced in Windows Vista:
The combination of these capabilities ensures that the new XPS Print Path in Windows supports completely the requirements for high quality color printing, including color printing commonly referred to as ‘16-bit’.
What other pieces are needed?
In the section above we drilled into the platform capabilities provided by the XPS Print Path. But platforms are platforms and not complete solutions. So the obvious question to ask is what other components are involved in ensuring that when a user hits “CTRL-P”, application high quality color data gets to high quality color marks on media. Unfortunately you don’t automatically benefit just because the print path now supports extended color.
Because I’m a bear of very small brain and find pictures=better, here’s a (very) high level diagram of the major pieces:
A sample implementation
Looking to try this out? We’ll here’s one setup to experiment with on Windows Vista:
Some Additional Resources on Microsoft WHDC
 Although remember that as gamuts are 3D volumes, 2D representations can give a misleading impression.