If you're not familiar with Printing Architecture and some of the concepts are unfamiliar, we did a post on Basic Printing Architecture a few months ago.
Each print queue is always associated with a print processor. A print processor is a spooler plug-in which supports one or more data types. These are the valid data types for print jobs submitted to the mentioned queue. Some example of data types are RAW and EMF. The meaning of “RAW” is dependent on the print processor. The Windows winprint print processor supports RAW, TEXT and EMF. WinPrint does very little processing with RAW print jobs. Basically, it assumes that the job is already in the page device language (PDL) and simply sends the data "as-is" to the printer device over the appropriate protocol. RAW requires very little processing on the server.
WinPrint can do a variety of things with EMF jobs such as N-Up, Booklet printing and Collation. Other custom print processors may provide more features. EMF requires more system resources because the print processor invokes the GDI/Printer driver to convert from GDI commands to the printer language. If a queue on a server accepts only RAW data type (in other words, the advanced printing features are disabled), then the conversion from GDI commands to PDL happens on the client. The print processor is not invoked at all on the client, hence the loss of advanced features.
So how do problems related to Advanced Print Features actually manifest themselves? The most common issue is when the client and the server have mismatched driver versions. When this occurs, the client and the print processor on the server may not be able to reconcile some features when using EMF Printing. Disabling the Advanced Print Features (forcing RAW) is a way to test the behavior, and even as a short term workaround where the scope of the issue is greater than one or two client machines.
Remember however, that if Advanced Printing Features are disabled, then the client may lose not only the ability to perform the advanced features that WinPrint provides, but any features provided by custom print processors, such as Watermarks, forcing a change in the paper size, secure / delayed print etc) may also be unavailable. That is why when you are troubleshooting problems that occur with a small number of print queues, the first step should not be to completely remove all OEM print processors. Although cleaning up the print key (as we refer to it) and switching all the printers to WinPrint will provide basic printing functionality - that's all it will do. However, you may actually make the problem much worse - users may experience issues where blank pages are printing, columns are not aligned correctly and text is misaligned, to name just a few of the common symptoms.
A better troubleshooting method is to select one print queue that uses the suspected driver model that is experiencing the issues and change its print processor to WinPrint. Then test the printer thoroughly to ensure that at least the basic print functionality performs as expected. If so, then you can change the other print queues using the same model and processor to WinPrint as a temporary fix. At this point, with basic print functionality restored you should contact the OEM for the problem print processor for additional assistance and a long-term solution.
That will do it for this post. As we've mentioned before, troubleshooting printer issues can be a very tricky business - especially in larger, more complex environments. Understanding what the underlying components provide within a printing environment can go a long way to diagnosing, isolating and resolving these issues.Microsoft, Windows, Printing, Troubleshooting, Knowledgebase, Article
Source:→ Performance Team Blog