Browse DevX
Sign up for e-mail newsletters from DevX


Empower Your Printing with Custom Print Processors : Page 2

Using Custom Print Processors is one of the many ways to take control of the printing process. Find out how to use this user-mode DLL and C/C++ to enforce security policies, add missing printing functionality, or alter print jobs.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Exported Functions
It's time to take a look at the interface between the Windows Print Spooler and the Print Processor DLL. Table 1 lists and explains the roles of the six functions you'll need to export.

Function Name



Retrieves data types that are supported by the Print Processor


Gets capabilities of the Print Processor with respect to a specified data type


Opens the print processor and obtains its handle at the beginning of the printing session


This function converts the spooled Print Job to the Printer Device language


Sends control requests to the print processor to pause/stop/continue printing


Closes the print processor when the printing session is over

Table 1. Exported Print Processor Functions

Frontiers: What Can You Do with Print Processors?
Since a stop at the Print Processor is mandatory for every print job, developers have almost unlimited control over printing activities. As the previous section states, every Print Processor must inform the Windows Spooler of the supported data types. Each type is handled differently and the level of control varies. For example, the RAW data type represents the data in the Printer Driver-specific format. If you want to examine the contents of a RAW print job, you need to write a device-specific handler. This narrows your range of supported printers.

Fortunately, most Windows Applications spool print jobs in NT EMF (the device-independent Extended Meta File format). EMF is documented and makes it easier to look at the actual data being printed. The Print Processor translates the EMF job to the device language by playing EMF records on the printer device context with the help of the Windows GDI API. When developing your own Print Processor, you are free to call upon GDI functions to alter a print job.

Print Processors handle all print jobs using the security context of the NT/2000/2003 domain account that issued the print job. This means you can identify a user from within your code and enforce any security policy you wish. For example, you can block the job for specific users if their Exchange mail box is too large. Print Processors are extremely useful for security, because simply defining the Access Control List for the printer cannot set these kinds of complex permissions.

What You Need to Start Coding
First, you'll need to configure your development environment:

  • Install Microsoft Visual Studio 7
  • Install Windows DDK 2000 (or higher)
Both products are supplied with a subscription to the MSDN CD/DVD package.

When developing Print Processor DLLs, you can use either the DDK build tool from the command line or an IDE, such as VS6 or VS7. The sample provided with this article was developed with Visual Studio 7.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date