Printing is one of the most common things we do with our PCs even as we read and work with more online resources. We set out to simplify and improve this common operation--working with partners across the ecosystem to deliver these improvements in Windows 8. This blog post was authored by Adrian Lannin, a lead program manager on the Printing team.
--Steven
Of all the peripheral devices that you can connect to your Windows PC, printers are one of the most popular, and have been supported for the longest time. In fact, Windows 1.0 (shipped in 1985) supported “a number of printers and plotters” and included a “Print Spooler [which] allows the user to work on one file while printing on another” according to the Windows 1.0 Press Kit. The screenshot of Windows 1.0 below shows the files included with that version of Windows – Epson.drv, lots of font files, and the print spooler process. Some parts of the print system are older than the people who work on it.
Over the years, the print system has evolved into a complex architecture that supports printing to a huge variety of printers, and can scale from a simple $50 inkjet at home to a high-availability print server hosting thousands of print queues for hundreds of thousands of users, driving printers that cost tens of thousands of dollars each.
The print system touches many layers and facets of Windows. It shows UI, and it hosts drivers that also show UI. It performs intensive graphics operations, since printing is essentially re-drawing your on-screen content onto paper. It encompasses lower-level communications, mainly USB or network (the majority of printers bought in the US today are network-capable, but our telemetry data tells us that over 75% of the printers installed with the Windows 8 Consumer Preview are plugged into a USB port). The print system needs to scale to very large, mission-critical deployments in large businesses but also run efficiently on small systems.
In this blog post I’m going to talk about the work that we've done in Windows 8 to re-imagine how the print system can best provide good device support to our customers. I'll show you how it works on ARM-based PCs and in Metro style apps. And I'll talk about what we've done to ensure that the maximum number of existing printers "just work"—whether you're accessing them from the desktop, from a Metro style app, or on a device running Windows RT.
[h=3]Reimagining the print system for Windows 8[/h] In Windows 8 we've introduced a new printer driver architecture, which we call version 4, or v4. The v4 architecture produces smaller, faster printer drivers, and it supports the idea of a print class driver framework--a system that allows people to install their printers without having to locate a driver for that device, in many cases.
As you've probably guessed, V4 is the fourth iteration of the printer driver architecture in Windows. V3 was the architecture used from Windows 2000 to Windows 7, and it’s actually still fully supported in Windows 8 for device compatibility reasons. So if you only have an existing driver available for your current printer, then it should still work in Windows 8. Versions 1 and 2 were the driver architectures for Windows 1.0 through Windows ME.
Before I explain how the print system works, I’d like to talk about some of the requirements that we worked to address with the Windows 8 print system.
[h=4]Printing from Metro style apps[/h] One of the things that we needed to figure out was how to give Metro app developers the ability to print. Printing from win32 applications requires knowledge of graphics programming, either GDI (Graphics Device Interface) or XPS (XML Paper Specification). When we looked at how we could make printing possible from Windows 8 apps, we completely reinvented how we enable printing from the Windows Runtime, and we made printing very easy to use from HTML5/JavaScript and XAML/C# apps.
[h=4]Integrating printing into Metro style apps[/h] Printing from a Metro style app should naturally be a Metro style experience. I’m sure that when most of you have printed something, you've seen a little applet pop up to tell you that the printer is out of paper, or to offer you the opportunity to purchase ink.
These pop-ups are very common with inkjet printers. Some pop up only when relevant (you have low ink), while others pop up every time you print. These pop-ups come from the printer driver software itself, and they are all desktop UI, of course. But when printing from the Metro style Photos app, for example, we don’t want you to have to switch over to the desktop just to see UI that tells you that printing is in progress.
[h=4]Printing in Windows RT[/h] Printer drivers have evolved over time 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 in use since Windows 2000 evolved into a highly complex and highly extensible model, which allowed printer manufacturers a lot of freedom in what is installed with their driver software. When we thought about how this would work on some of the devices that are going to run Windows RT, we knew that we had to make some significant architectural changes. We really wanted to ensure that we didn’t negatively impact ARM systems by running unnecessary services, and we wanted to reduce system resource usage, while still providing support for as many devices as possible.
[h=4]Lots of printers supported, far fewer drivers[/h] 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 these tend to be large and resource hungry). This meant that the number of drivers that we included with Windows (we call these in-box drivers) was very large so as to provide good support. Of course, we have many more drivers on Windows Update, but we believe that it’s important to have a core set of in-box drivers that support popular devices, so we can still provide a good printing experience for people who 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 lots of printers is that the 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, but as new devices were released over the years, and time went by, the set of drivers in Windows 7 became less relevant. One big challenge in Windows 8 then, is to ensure that Windows provides a high level of support for lots of printers, including ones that haven’t even been released yet.
[h=4]Printer sharing[/h] 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. Some of these difficulties you might encounter when you're trying to share a printer at home too, especially if you have both 32-bit and 64-bit versions of Windows. This becomes tricky because the print “server” (which just means the PC that the printer is connected to – not actually Windows Server) has to provide the drivers to the clients that want to print to the shared printer. In Windows 7, we used HomeGroup to address this problem, and it works well much of the time. However, the requirement to load drivers for each Windows architecture becomes more problematic when you think about printing from Windows RT.
Although we expect that most people who print from Windows RT devices are likely to print to wireless printers, we didn’t want to totally exclude the possibility of printing to a USB printer. On the other hand, we 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! So, with the v4 model in Windows 8, we developed a new way to share printers that doesn't rely on putting client drivers onto the print server.
[h=3]The print system in Windows 8[/h] Applications enable you to 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 what particular device is installed. I’m going to talk a little about how the app prints, and go into more detail about how we get the content onto a printed page.
[h=4]Creating printable content[/h] For apps, adding printing support is quite straightforward. The content that you want to print from an app is in a format that the app specifies. For Metro style 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 that the print system needs to do is to translate the content from the app's format to the format that the printer understands. Unfortunately, printers don’t all understand the same formats (not even close!) 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 a high quality intermediate format called XPS (XML Paper Specification) as its internal content format; we convert the content from Word into XPS. We chose to use XPS as the foundation of our print system because it is a very flexible format and is just like electronic paper. It supports high-fidelity color, and since it’s an XML-based description with no executable code embedded, it’s great for archival purposes and it is secure compared to other options. In addition, Microsoft has worked with ECMA International (European Computer Manufacturers Association) to make it an open standard (ECMA standard TC46, OpenXPS). Both the desktop viewer and the Reader app can display OpenXPS. I “print” all my receipts from online purchases as XPS files.
Once the content is being managed by the print system, it is then converted to the format that 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, and the job prints.
In Windows 8, we have a distinct improvement to this story because all Metro style 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. Reader’s 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 is different from the screen layout, then 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!
Now that you understand in broad terms how an app sends print information to the print system, I’m going to talk about what the system does with that, the services it provides, and what else has changed in Windows 8.
[h=3]Supporting lots of printers[/h] One of the big benefits that Windows provides to apps is that it abstracts the specific printer from the app, so that the app's programmer doesn’t have to worry about what printer you've installed. Windows supports tens of thousands of printer models in total, including printers that are supported by drivers available via Windows Update or the manufacturer’s website. When we see printers that don’t work, this is often because the manufacturer has chosen to block the installation if they don’t recognize the version of Windows that their software is being installed on. We work with printer manufacturers to get these packages updated, but this does take some time.
Ideally, when you plug a new printer into Windows, it just works, without your needing to go off and find drivers.
So how do we make that happen? In the past we've shipped a lot of printer drivers in Windows. Vista contained about 4500 drivers, and Windows 7 contained about 2100 drivers. Even though Windows 7 had half as many drivers as Vista, it provided better market coverage, by which I mean that there was a better chance that it had a driver for the more popular printers. Why is this? There is an incredible diversity of printers in use. In Vista, we supported a lot of devices that were old and no longer in popular use, and so the relevance of the set of devices supported was not as good as in Windows 7.
As an aside, the other thing we do when we release a new version of Windows is to take the drivers that were in the previous version and post them to Windows Update, so that even though these devices may be dropping in popularity, it’s still possible for people to automatically get the device working by just plugging it in.
Here's a photo I took of one of the benches in one of the printer labs (we have several) where we test that this all works. You can see several small inkjets and laser printers from different manufacturers. Luckily for my ears, we don’t test with dot matrix printers very often these days.
People tend to keep printers for 5-7 years on average, so when we want to add support, we have to think "what devices are people using? Which were the most popular devices over the past several years, and what will be the most popular in the future?" This last part is tricky because, pretty soon after we release Windows, the printer manufacturers will release devices that we didn’t know anything about. This means that over time, the set of devices that we support in any particular version of Windows becomes stale.
We know that at any given moment, about 100 specific printer models make up about 50% of the installed base. If we want to support 75% of the models being used today, then we need to support about 300 models. The diagram below illustrates this.
To get to 95%, we need over 1000 models supported. But the problem is even harder because the printers that make up this set of 100, or 300, or 1000 changes all the time. The 100 printers that represent 50% of the market today are not the same 100 printers that will represent 50% next week, or next month, and especially not next year. Every day, many people buy and install new printers.
As I mentioned above, we basically took a brute-force approach to solving this in the past. We have 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 just isn’t very efficient.
In Windows 8, we took a radically different approach, and have 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, but it also allows manufacturers to include support for new devices, even those that have not yet been designed.
With a print class driver framework, we can get closer to giving you an experience like driverless printing, where you don't have to actually go and find a driver, but instead the printer just works with the Windows printing system. A true driverless printing experience requires changes to how most printers are designed, and the print class driver framework provides support for this idea, but we also feel that it’s very important to provide as much support for existing devices as possible.
With the ability to support new and planned printers, the number of printers that are supported by the Windows 8 print class driver framework will actually increase over time.
Besides the great progress in increasing the number of devices covered, we have also been able to reduce the resources that we use to achieve this coverage.
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 number is an average across different editions and architectures of Windows 8. The following graphic illustrates the reduction in space used since Windows Vista.
Comparison of disk space needed to support printers and imaging devices in Windows 8, Windows 7, and Windows VistaIn addition, the reduction in disk space used has been accompanied by an increase in the relevance of the devices supported directly by Windows. The following table summarizes how the relevance of the inbox coverage has increased, while disk use has decreased.
This is a huge improvement in Windows 8, and this reduction in space used directly translates 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.
Approximate number of devices supported in-box
Approximate installed base
Disk space used
Windows Vista
4200
55-60%
768 MB
Windows 7
2100
60-65%
446 MB
Windows 8
2500
70% at release growing to 80%
184 MB
The Windows 8 printer driver model also allows us to focus our manufacturing partners on a set of code that will not change as much from one version of Windows to the next, so we will be able to more usefully spend those resources on improving quality and performance, instead of constantly repopulating the driver set.
[h=3]Print class driver architecture[/h] Besides wanting to create an architecture that supports the needs of Windows RT and Metro style apps, we wanted to make sure the model would also work with existing devices, and would utilize technologies that were familiar to printer manufacturers, so that it would be easier for them to implement the new driver technology.
A printer driver does several key things:
[h=4]Configuration UI[/h] One big change between the old driver model and the Windows 8 driver model is in how the UI is provided. In the old printer driver model, the configuration UI was built into the driver. Here's an example of some typical printer UI (taken from the Epson NX430 that is currently on my desk).
- Configuration allows the user to change settings, translating the intent to turn on double-sided printing (for example) into the specific command that the printer needs for this. Configuration is presented to the user through the user interface.
- Rendering translates the printed content from the format that Windows print system uses into the format that the printer understands. In some cases, the printer may directly understand the native Windows print format (XPS), so for those devices, there is no work to do here, unless they want 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.
- Events allow the printer to inform the user that something has happened – a job has completed, there has been a paper jam, or the printer is out of ink.
As I mentioned earlier, we needed to find a way to enable the display of Metro style UI when people wanted to change printer settings.
In the Windows 8 driver model, the manufacturer’s UI is completely separate from their driver. This is a much better architectural decision for many reasons: The UI to control the printer is now an app that can be invoked when printing from Metro style apps or desktop apps. This allows printer manufacturers to present you with a much richer experience – imagine access to video showing you how to set up your printer or install an ink cartridge.
Here is an example of a Metro style app that Epson has developed for the Epson NX430:
You can see that this UI has all the hallmarks of a Metro style app, but for your printer. It includes an attractive view of the ink levels of the printer, and is much easier to use, especially on touch-screen devices.
Windows will automatically show you the correct type of UI – desktop printer UI when you're printing from desktop apps, and Metro style UI when you're printing from Metro style apps.
If the manufacturer hasn't provided any configuration UI for their device, then Windows provides some standard UI that you can use with any printer. However, when the printer manufacturer has decided to invest in providing a customized experience for their device, they can provide an app that replaces the standard Windows UI. Then, when you decide to alter the configuration of the device, or when the device configuration changes during printing (e.g. paper jam), then Windows will display the manufacturer’s customized app to you instead.
[h=4]Rendering[/h] One of the most important functions of a printer driver is to take the content that the app produces when you ask it to print, and convert that into something that the printer can understand. This was one of the most challenging areas of building the Windows 8 print class driver, so let’s look at it in a bit more detail.
As described above, desktop apps like Word or Photoshop use graphics commands to draw their content onto the screen or the printer. When they do this, the print system receives the content, converts it into XPS if necessary, and then calls the printer's driver (or more specifically, the render filter part of the driver) to convert the content into the right format. This is sent to the printer and your file is printed out.
Probably one of the largest challenges in supporting a very wide range of printers is in dealing with the rendering portion of the problem. Some of the more expensive printers support standard “page description languages” or PDLs, such as PostScript, PCL, and XPS. However, 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 may have only a few languages that they use across their product line, but 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 being a complete printer driver and it’s easy to see that increasing support involves a steadily increasing number of drivers. Of course, this is a bit of a simplification and it is possible to create a driver that supports a number of devices, and we have often seen drivers that support a series of printers. But 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 device that describes how they are supported more generically. We call this a compatible ID. So for example, if a device has a compatible ID that says that the device supports XPS, then the print system knows that 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 that the device is a generic XPS printer and can treat it that way. Of course, Windows also understands that this is a Fabrikam 1000 printer (or whatever), so if there is a model-specific driver, then Windows will install it. But if there is no driver available, then Windows can still print to the printer using the class driver.
So in this example, we have a set of render filters in-box as part of the class driver model, and these can be installed for any device that implements a matching compatible ID. The logical extension of this idea is that it’s quite possible for future devices, devices not yet designed or built, 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 (many already do). Because of this capability, the number of printers that are supported in Windows 8 will increase over time, rather than decrease, and more and 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.
But what about all the devices that have proprietary rendering languages? The print class driver supports that model too, but with the disadvantage that we do need to have a separate rendering filter for each small set of models that speak each unique language. There is no way around this, and 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, and we expect to see manufacturers produce printers that can more easily utilize the class driver in the future.
[h=3]Printing from Windows RT[/h] The reduction in the resources used by the print class driver contributes directly to a smaller footprint for Windows, which is especially valuable on Windows RT. In addition, the V3 printer driver architecture was highly extensible and had evolved over many years into a model that encouraged the development of large, complex printer drivers. Some drivers install services that run all the time, exhausting battery power and using processor time. I've seen some drivers that support only one device but that are larger than the complete printer driver set in Windows 8!
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. I’ve already mentioned that the UI portion of the print experience is now a completely separate component, an app instead of being part of the driver. This means that it’s also optional, and 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 also 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,”—sort of like a database for all types of drivers. When you plugged in a printer, we would 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 have 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.
For a real world example, we compared the installation times for an Epson Artisan on Windows 7 versus Windows 8 (using a relatively small driver on Windows 7): the install time on Windows 7 was 14 seconds, compared to under 2 seconds on Windows 8.
[h=3]Final thoughts[/h] As you can see, the Windows 8 printer driver architecture is big step forward. It provides good support for a lot of the printers that people already own, and supports future devices with a small, fast, built-in class driver framework. The performance is great and the disk footprint is small.
We’re look forward to your feedback!
-- Adrian Lannin
More...
