Clear up some myths about PDF printer drivers
I'm sure you've heard sometimes phrases like "a printer driver which is based Windows GDI can only reproduce RGB colors" or "if a printer driver isn't built on top of the PostScript driver one cannot print EPS graphics". There is no question that these myths persist since PDF Producer software exists. In this article I'd like to give you some background information which helps you to understand how it really works.
The Microsoft Windows printing system architecture is well designed but not easy to understand. I don't want to confuse you with to much information and try to focus on the essential part, the printer driver. If you are an expert please apologize if I simplify too much. It's for the sake of better understanding.
You can think of a printer driver as the component which translates a device independent spool file (see below) into a device dependent one such as HP-GL, HP-PCL, PostScript, AFP and others.
In Microsoft Windows there are two device independent spool file formats: EMF and XPS. The traditional EMF (Enhanced Metafile) file format can be thought of a recording of calls to the Windows GDI (Graphics Device Interface) sub-system whereas the modern XPS (XML Paper Specification) is a page description language based on XML. EMF exists since the first version of the Windows operating system. XPS has been introduced with Windows Vista. There is no direct connection between GDI and XPS. However, for compatibility reasons the Windows printing system offers some built in 'translators' from GDI to XPS and vice versa. In the following I will concentrate on GDI and post a article on XPS later.
Most printer drivers are still based on GDI (and the EMF spool file format). This is especially true for the Windows PostScript printer driver, which has originally been a joint Adobe and Microsoft development. However, in order to enable printing applications to make use of the power of PostScript such as color spaces etc. GDI has been extended such that applications can directly inject PostScript code into the spool file. The PostScript injection feature, however, is the source of the confusion as we see later.
The majority of the PDF Producer software, including Adobe Acrobat, is built on top the the Windows PostScript printer driver. When an application prints a document using a PDF Producer software then it actually generates a spool file using the PostScript printer driver. The spool file is immediately translated to a PDF file by means of a print post processor such as Adobe Distiller. The advantage of the intermediate PostScript spool file is, on one side, that the software manufacturer can reuse the existing PostScript printer driver and doesn't need to develop and maintain a PDF printer driver. On the other side, the user must live with the implementation limits of the PostScript printer driver (it does not fully implement the GDI features) and with a slower performance.
A high quality and high performance PDF Producer software which is based on GDI can only be implemented by a specialized printer driver which directly produces a PDF document. This has the following advantages:
Performance: 50 to 100 pages per second (otherwise 10 times slower)
GDI function converage: 100% (otherwise limited by PostScript printer driver)
RGB and CMYK color spaces are directly supported by GDI
Support for the Windows color management system (CMS)
Support for the PostScript injection feature
As you can see, a specialized PDF printer driver can directly support the PostScript injection feature since the feature is available to any printer driver and is not limited to the PostScript printer driver.
Here's my take to clear up the myths: In order to use the power of PostScript in applications such as EPS graphics, spot colors etc. it is not required that a PDF Producer software is based on the PostScript printer driver and architectures that use it. In a high quality and high performance environment a PDF Producer that is built on a specialized printer driver is definitely the better choice.