Windows 8 and Windows RT rely on an entirely new printer driver architecture.
Windows 8 introduces a new printer driver architecture called version 4 (v4). The v4 architecture generates smaller, faster printer drivers. It also supports a print class driver framework. In many cases, this lets users install printers without having to locate a driver for that device.
V4 is the fourth iteration of the Windows printer driver architecture. Windows versions from Windows 2000 to Windows 7 used the v3 architecture. V3 is still fully supported in Windows 8 for device-compatibility reasons, so if you only have an existing driver available for your current printer, it should still work in Windows 8.
Printing from a Windows Store app should naturally be a Windows 8-style experience. When you’ve printed something, you’ve seen a little applet pop up to tell you that the printer is out of paper or running low on ink. These pop-ups are common with inkjet printers. Some pop up only when relevant (you have low ink), while others pop up every time you print. They come from the printer driver software itself.
Printer drivers have evolved to include a lot of functionality. Some install services, some install numerous little applications, and many are now quite large. The v3 printer driver model Windows has used since Windows 2000 has evolved into a highly complex and highly extensible model. This gives printer manufacturers considerable freedom in what they install in their driver software. When we thought about how this would work on some of the devices that will run Windows RT (the version of Windows 8 optimized for mobile use), we knew it needed significant architectural changes. We didn’t want to negatively affect systems by running unnecessary services. We wanted to reduce system resource usage while continuing to support as many devices as possible.
There’s a huge diversity in printer capabilities, and Windows supports a vast range of printers. In Windows 7 and earlier versions of Windows, each of these printers required a specific driver in order to work (there are some exceptions, such as universal printer drivers, but those tended to be large and resource hungry). This meant the number of drivers that were included with Windows (called in-box drivers) was quite large so as to provide good support.
There are many more drivers on Windows Update, but it’s important to have a core set of in-box drivers that support popular devices in case a user can’t or won’t download a driver from Windows Update. In-box drivers are essential for Windows RT. In fact, it uses only in-box printer drivers. The challenge here is to get a relevant set of printers supported, but to also reduce the resources required to accomplish this.
Another interesting challenge in supporting numerous printers is support gets stale over time. The set of drivers included in Windows 7, for example, provided excellent support for devices released in 2008 and 2009. As new devices were released and time went by, the set of drivers in Windows 7 became less relevant. One big challenge in Windows 8 is to ensure that Windows continues to provide a high level of printer support, including printers that haven’t even been released yet.
Anyone who has administered a print server can tell you that getting the correct drivers installed to support sharing is the most time-consuming part of managing a print server. This becomes tricky because the print “server” (which just means the PC to which the printer is connected, not actually Windows Server) has to provide the drivers to the clients that want to print to the shared printer.
In Windows 7, Microsoft used HomeGroup to address this problem. It works well much of the time. However, the requirement to load drivers for each Windows architecture becomes more problematic when you need to print from Windows RT.
Although most people who print from Windows RT devices are likely to print to wireless printers, Microsoft didn’t want to totally exclude the possibility of printing to a USB printer. On the other hand, Microsoft didn’t want to increase the complexity of printer sharing by requiring people to add drivers for 32-bit clients, 64-bit clients and Windows RT clients.
Applications let you create and view content. The purpose of the print system is to provide these apps with the means to print your content to any installed printer without having to worry about which particular device is installed.
For apps, adding printing support is quite straightforward. The content you want to print from an app is in a format that the app specifies. For Windows Store apps, this will often be HTML5 or XAML, but for Win32 apps such as Word or Photoshop, the content is in a format specific to each particular app.
So when you want to print from an app to your printer, one of the things the print system needs to do is translate the content from the app’s format to the format the printer understands. Unfortunately, printers don’t all understand the same formats, so this turns into quite a bit of work.
To give a real example, an app such as Word uses the GDI graphics system to draw the content both to the screen and to the printer. When possible, the print system uses XPS (a high-quality intermediate format) as its internal content format. Then Windows converts the content from Word into XPS.
XPS is the foundation of the print system because it’s a flexible format and is just like electronic paper. It supports high-fidelity color, and because it’s an XML-based description with no executable code embedded, it’s great for archival purposes. It’s also secure compared to other options. In addition, Microsoft has worked with the European Computer Manufacturers Association (ECMA) International to make it an open standard (ECMA standard TC46, OpenXPS). Both the desktop viewer and the Reader app can display OpenXPS.
Once the content is being managed by the print system, it’s converted to the format the printer understands (if necessary—there are lots of printers that understand XPS directly), and the print system sends this to the printer with the correct options set. Then the job prints.
In Windows 8, there’s a distinct improvement to this story because apps use Direct2D as their basic drawing format, and Direct2D and XPS share the same XML-based graphics language. So in another real-world example, the Reader app uses Direct2D to render its content onto the screen. It also uses Direct2D to render the same content to the print system. The Reader content can easily be submitted to the print system as XPS, without any costly conversion from GDI.
If the app requires a print layout that’s different from the screen layout, it can do this using style sheets or XAML. This means that you don’t have to “click here for a printer-friendly version of this page.” If you have a printer that supports XPS, then the path from the app to the printer involves no conversions at all, and printing is extremely fast.
And that, in broad terms, is how an app sends print information to the print system. Next month, I’ll cover the broad spectrum of printers that Windows 8 supports.