Windows 8: Painless printing
There’s an entirely new printer support architecture built in to Windows 8 that will improve support both now and in the future.
Adrian Lannin
Ideally, when you plug a new printer into a Windows machine, it should just work. You shouldn’t have to go off and find the right driver. That’s one of the big benefits of Windows 8. It abstracts the specific printer from the application, so you don’t have to worry about what printer you’ve installed.
How did my team and I make this happen? We’ve previously shipped a lot of printer drivers with earlier versions of Windows. Windows Vista had about 4,500 drivers, and Windows 7 had about 2,100. Even though Windows 7 had half as many drivers as Windows Vista, there’s a better chance it had a driver for the more popular printers. In Windows Vista, we supported a lot of older, no longer widely used printers, so the relevance of the supported devices supported wasn’t as good as in Windows 7.
Windows supports tens of thousands of printer models in total. This includes printers supported by drivers only available via Windows Update or the manufacturers’ Web sites. When we see printers that don’t work, this is often because the manufacturer has chosen to block the installation. We work with manufacturers to get these packages updated, but it does take time.
When we release a new version of Windows, we take the drivers from the previous version and post them to Windows Update. Even though these devices may drop in popularity, you can still just plug them in and automatically get the device working.
The printer population
People tend to keep printers for five to seven years on average. When we want to add support, we have to think ahead and ask questions like, “What devices are people using? Which were the most popular devices over the past several years? What will be the most popular in the future?”
That last part is tricky because soon after we release new versions or updates to Windows, the printer manufacturers release devices we didn’t know about. This means that over time, the set of devices we support in any particular version of Windows becomes stale.
At any given moment, about 100 specific printer models make up about 50 percent of the installed base. If we want to support 75 percent of the models currently in use, we need to support about 300 models.
To get to 95 percent, we need to support more than 1,000 models. The problem is even more difficult because the printers that make up this set of 100, 300 or 1,000 change all the time. The 100 printers that represent 50 percent of the market today aren’t the same 100 printers that will represent 50 percent next week or next month, and especially not next year. Every day, many people buy and install new printers.
We’ve taken a brute-force approach to solving this in the past. We’ve had representatives from the major printer manufacturers working directly with Microsoft, sitting in offices in Redmond, working to check their source code into Windows. They would create a completely new set of in-box drivers for each new release of Windows. This worked, but wasn’t very efficient.
In Windows 8, we took a radically different approach. We stopped shipping lots of printer drivers with Windows. Instead, we built a print class driver framework. This framework is extensible, as it supports printing to existing devices. It also helps manufacturers support new devices, even those that haven’t been designed. With the ability to support new and planned printers, the number of printers the Windows 8 print class driver framework supports will actually increase over time.
With a print class driver framework, we can get closer to providing a driverless printing experience. You won’t have to actually go and find a driver. Instead, the printer just works with the Windows printing system. A true driverless printing experience requires changes to how most printers are designed. The print class driver framework supports this idea, but it’s also important to provide as much support for existing devices as possible.
Resource reduction
Besides making great progress in increasing the number of supported devices, we’ve also been able to reduce the amount of resources required. First, we reduced the amount of disk space needed to support printers and imaging devices from 768MB in Windows Vista to about 184MB in Windows 8. This is an average across different editions and architectures of Windows 8. We’ve also increased in the relevance of the devices supported directly by Windows.
This is a huge improvement in Windows 8. This reduction in space translates directly into more available storage space for users of hardware with limited storage capacity, which we expect will be a characteristic of some Windows RT computers.
The Windows 8 printer driver model helps us focus our manufacturing partners on a set of code that won’t change as much from one version of Windows to the next. We’ll be able to more usefully spend those resources on improving quality and performance, instead of constantly repopulating the driver set.
Print class driver architecture
Besides creating an architecture that supports the needs of Windows Store apps, we wanted to ensure the model would also work with existing devices. It had to use technologies familiar to printer manufacturers, so it would be easy for them to implement the new driver technology.
A printer driver does several key things to begin the printing process:
- Configuration lets you change settings, translating the intent to, for example, turn on double-sided printing into the specific command the printer needs to be able to do this. You can adjust configuration options through the UI.
- Rendering translates printed content from the format the Windows print system uses into a format the printer understands. In some cases, the printer may directly understand the native Windows print format (XPS). For those devices, there’s no work to do here, unless a users wants to do extra rendering (doing multiple pages per physical sheet of paper is an example of this case). The part of the driver that does rendering is called the render filter.
- The printer informs the user something has happened with event notifications—a job is complete, there’s been a paper jam or the printer is out of ink.
Configuration interface
One big change between the old driver model and the Windows 8 driver model is how the interface is provided. In the old printer driver model, the configuration UI was built in to the driver. In the Windows 8 driver model, the manufacturer’s UI is completely separate from its driver. Windows 8 will automatically show you the correct type of UI.
This is a better architecture for many reasons: The UI to control the printer is now an app you can invoke when printing from Windows Store apps or Windows desktop apps. This helps printer manufacturers present you with a much richer experience.
If the manufacturer hasn’t provided a configuration UI for its device, then Windows provides a standard UI you can use with any printer. However, when the printer manufacturer has decided to invest in providing a customized experience for its device, it can provide an app that replaces the standard Windows UI. Then, when you decide to alter the device configuration or when the device configuration changes during printing (such as during a paper jam), Windows will display the manufacturer’s customized app instead.
Rendering
One of the most important functions of a printer driver is to take the content the app produces when you ask it to print and convert it into something the printer can understand. This was one of the most challenging areas of building the Windows 8 print class driver.
Apps like Word or Photoshop use graphics commands to draw content onto the screen or the printer. When they do this, the print system receives the content and converts it to XPS if necessary. It then calls the printer’s driver (or, more specifically, the render filter part of the driver) to convert the content to the correct format. This is sent to the printer and your file is printed out.
Probably one of the largest challenges in supporting a wide range of printers is dealing with rendering. Some of the more expensive printers support standard page description languages (PDLs) such as PostScript, Printer Command Language (PCL) and XPS. Less-expensive, consumer-focused devices are manufactured with cost savings in mind, and many of these support proprietary methods of sending the page information to the printer.
Some manufacturers only have a few languages they use across their product line. Others may tweak the language from one model to the next, trying to get the most out of their printer hardware. This leads to a 1-1 mapping between printer driver and printer hardware.
Imagine each PDL as a complete printer driver. It’s easy to see that increasing support involves a steadily increasing number of drivers. This is a bit of a simplification. It’s possible to create a driver that supports a number of devices. We’ve often seen drivers that support a series of printers. The key point here is that Windows 7 and earlier versions of Windows didn’t do anything to support this design approach.
The printer driver model in Windows 8 supports the idea that a PDL (or driver) can be associated with multiple devices. We’ve been working with our printer manufacturer partners to have them include an identifier in their devices that generically describes how they’re supported. We call this a compatible ID. If a device has a compatible ID that says the device supports XPS, then the print system knows it doesn’t need to find a model-specific driver for that device. It can just install a generic XPS driver for the device.
Windows understands the device is a generic XPS printer and can treat it that way. Of course, Windows also understands it’s a Fabrikam 1000 printer (or whatever), so if there’s a model-specific driver, then Windows will install it. If there’s no driver available, Windows can still print to the printer using the class driver.
So, in this example, there’s a set of render filters as part of the class driver model. You can install these for any device that implements a matching compatible ID. The logical extension of this idea is that it’s quite possible for future devices to be compatible with the print class driver in Windows 8.
We’ve been working with the printer manufacturers, and they all plan to implement compatible IDs in their devices. Because of this, the number of printers supported in Windows 8 will increase over time. More people will get the experience of being able to use their printers instantaneously from Windows 8 without the need to go and find a driver.
What about all the devices that have proprietary rendering languages? The print class driver supports that model too, but with the disadvantage of needing a separate rendering filter for each small set of models that speak each unique language. There’s no way around this. In Windows 8, we’ve taken a number of filters that address a set of popular models. However, once again, we’ve been working with the printer manufacturers to improve this position. We expect to see manufacturers produce printers that can more easily use the class driver in the future.
Printing from Windows RT
The reduction in the resources used by the print class driver contributes directly to a smaller footprint for Windows. This is especially valuable on Windows RT. The version 3 printer driver architecture was highly extensible and had evolved over many years into a model that encourages the development of large, complex printer drivers. Some drivers install services that run all the time. This can exhaust battery power and waste processor time.
The need to support printing in Windows RT, and a general desire to make printing more efficient, led us to develop an architecture that more tightly controls what the driver can do. The UI portion of the print experience is now a completely separate component—an app instead of part of the driver. This means that it’s also optional. Drivers will work well with the standard Microsoft printing UI. We’ve also simplified the driver architecture to be more power-efficient by removing service dependencies and reducing the likelihood that additional software will be included with the driver.
With the Windows 8 driver model, we made significant changes to how printer drivers are installed. In Windows 7 and earlier versions of Windows, all printer drivers are stored in the Driver Store. When you plugged in a printer, we’d find the correct driver in the driver store and copy it to a special location where the spooler could use it with your printer. In Windows 8, we’ve eliminated this extra copying, which removed quite a bit of disk I/O. The print spooler now just knows how to find the driver in the driver store.
The Windows 8 printer driver architecture is a big step forward. It provides good support for a lot of the printers that people already own. It will also support future devices with a small, fast, built-in class driver framework. The performance is great and the disk footprint is small.
.jpg "Adrian Lannin")
Adrian Lannin is the lead program manager for Printing and Scanning in Windows, and for Windows To Go. Within these areas, he’s responsible for designing and shipping features for enterprise users as well as home users. Lannin has more than 25 years of experience in the imaging industry.