Printing in Windows

Printers are a lot like people. Oh, I don't mean that they are cantankerous, or that they quickly run out of ink. Like the people of the world, printers speak many different languages. At the basic end of the language scale, many printers simply output the characters they receive. Others add "escape sequences," special combinations of characters that enable special features like font selection or double-wide text. At the complex end of the scale is PostScript, an English-like printer language with commands that are somewhat similar to those in GDI+.

It would be every programmer's worst nightmare to adjust application code so it targets all likely printers that a user may have. Each new printer language would mean another bout of development and testing. And printer makers are just giddy enough to come up with new language variations on a monthly basis.

Fortunately, Windows implements a system of printer-specific drivers that shield the developer from most printer variations. These drivers all speak a common languagelet's call it "Printish"which the driver translates into the printer's native tongue. As developers, we need only design software that speaks Printish.

The .NET Framework's printing system adds yet another level of language translation. .NET programs do not directly communicate with the printer drivers. Instead, they use GDI+ commandsthe same commands used for screen updatesto output content to an in-memory printer canvas. The Framework then converts these commands to Printish and sends the output on to the appropriate printer driver, and finally to the printer. Figure 19-1 shows a summary of the steps involved in .NET printing.

Figure 19-1. From programmer to canvas: printing with .NET