Universal Printer Drivers

Each year millions of printers are sold worldwide. Even though it is difficult to find reliable estimates on how many different printer models are in use worldwide, the numbers of printer drivers included in Microsoft operating systems provide a good indicator of printer diversity.

Considering that these numbers only include the OEM version of printer drivers and not the various other driver versions that are for download from manufacturers websites to support additional features, it becomes clear that managing even smaller but diverse printer deployments is challenging and managing large print environments is basically impossible. The challenges that come with the amount of printer drivers are manifold and include incompatibility issues, negative impacts on system stability and performance as well as intensive and time-consuming test and deployment cycles. A single universal printer driver for any kind of printer is as desirable as it is difficult to find. Currently three concepts have emerged to take on this challenge:

• Standardization of printers
• Converting print data into a generic format and having it interpreted and rendered into a print job on a remote computer
• Redirecting print data from the print subsystem of the computer that prints to the print subsystem of another computer in the network where the rendering of the print job is done.

Each of these approaches comes with its own challenges. Standardizing of print devices will lead to a small number of required printer drivers. It is, however, only possible in small companies in which the need for a universal printer driver is generally low anyway. Larger enterprises with conflicting print requirements are struggling to find a common denominator for print devices that match everyone’s need. The short life cycle of printers further complicates standardization efforts because by the time a standard has been developed, tested and is deployed many of the chosen printer models will be out of production. Usually only industries with very specific and therefore very coherent printing needs should explore printer standardization to reduce printer driver management.

Converting print data created by an application into a meta-format is used by universal printer drivers from less tech-savvy companies. Even though it is relatively simple to license a PDF writer, Postscript driver or just a simple module that creates a bitmap of each page of a print job, this category of universal printer drivers inheres several shortcomings in regards to performance, scalability and compatibility.

The most obvious limitation is determined by the chosen meta-format e.g. jpg, pdf, PCL or variations of PostScript. Each of these formats comes with its own complexity. This means that significant CPU and memory resources are required on the machine that creates the meta-format. Even though, smaller print jobs that are evenly distributed throughout the work day, will not have a drastic impact on the performance of a virtual host or a terminal server, large print jobs, complex print jobs and bursts of print activity will be noticed negatively.

While servers can be designed to handle bursts of print activity for a premium, the structure and complexity of the meta-formats cannot be adjusted. No current meta-format retains all information of a Windows print job. This loss of information is likely not noticeable for many users and intensive testing can help assuring that currently used applications, documents and printers work correctly. However, picking a meta-format printer driver requires trusting that the chosen technology will still be around and compatible with future printing requirements, applications and documents.

The most technologically advanced way of avoiding managing printer drivers on centralized systems is to redirect the print data an application creates to a remote computer that uses the same type of print subsystem and has the required printer drivers installed. Doing this EMF-redirection - when done with components that are completely embedded into the Windows print systems and certified by Microsoft, delivers not only a highly efficient universal printer driver but also the highest degree of flexibility and scalability by providing the base for clustering, printer pooling, queue prioritization, multiple queues, printer shares, setting security permissions, etc. Meta-format based universal printer drivers usually lack the support for these kinds of setups.

Another major reason to use an EMF based solution is performance. Removing the print rendering from a virtual host or terminal server not only removes the need for printer drivers on that server but also reduces print related CPU and memory utilization. Because the EMF format can simply be put into the print system of the remote Windows machine, there is no additional performance hit on the receiving machine either. The receiving print subsystem treats the EMF data as if an application is printing and renders it according to the configuration of the printer queue the data is moved into. On the other hand, Meta-format based universal printer drivers need to interpret the Meta-format on the receiving computer and literally print the document a second time.

Independently from whether a meta-format or EMF format based universal printer driver is used, it is important to consider how a specific solution is designed and implemented. Many universal printer driver solutions remove the print data from the Windows print subsystem and process it with proprietary modules. From a technical stand point, it is a risky decision to bypass the print subsystem which was designed and developed in conjunction with the operating system and its reliability has been proven with the largest companies and the most complex IT environments. The likelihood of problems grows with the number of components involved and adding proprietary modules and services to handle print jobs outside of the print subsystem is a significant source for problems. Furthermore, taking the print process away from the Windows print subsystem means that Microsoft and likely application vendors, too, will not support potential issues with printing.

One important fact to consider is that not all printer specific features are available to users. Being universal usually means that only the standard Windows printer settings are directly configurable. However, the design of some solutions allows for the option of having print specific settings pre-defined by an administrator or in case of printing via a remote desktop session to be configured through the local printer driver GUI. This creates a certain inconvenience for users that require features like stapling, watermarks, bin sorting, etc.

Besides trusting the software itself, which will eventually be handling printing for hundreds or thousands of users and printers, the manufacturer’s ability to troubleshoot and resolve problems in a timely manner has to be taken into account as well. This is especially important considering that many manufacturers of universal printer driver solutions employ less people than the number of IT administrators of a mid-size company. The lack of development resources of such companies is often the reason for using meta-formats in the first place, taking shortcuts and being less flexible.

The fastest way to evaluate whether a universal printer driver solution is ready for an enterprise environment is by asking what alternatives can be used if certain applications, operating systems or printer models do not work well with the universal printer driver. If the answer shows that the product in question follows a one-way-works-for-all approach then administrators and decision makers should steer clear of it. If Windows-based printing would be that simple, then there wouldn’t be a need for a universal printer driver in the first place. A sure sign that a product is not suited to fill the role of a strategic, enterprise-wide print solution is the inability to be used on print servers with universal printer driver queues that can be shared to desktops and user sessions.

ThinPrint .print’s modular architecture allows for the usage of any printer driver as the universal driver for a group of printers as long as they understand the same printer language. For true device independence, ThinPrint developed the ThinPrint Output Gateway. It is a universal printer driver that provides Driver Free Printing. Even though it looks like a printer driver and has all the properties and interfaces of a printer driver to provide full usability by applications, users and the print subsystem, it does not perform the actual task of a printer driver. Instead of rendering EMF data - the format an application creates - into RAW data – the format a printer can process - the ThinPrint Output Gateway guides the EMF data through the print subsystem without modifications besides optimization for compression. Since the EMF data is not modified, ThinPrint software can simply move it into another printer queue for rendering. This can be a printer queue on the same machine or a printer queue on a remote machine.

If the receiving queue is on a remote computer then the ThinPrint Output Gateway queue utilizes a ThinPrint Port to transfer the EMF data over the network. The machine hosting the receiving printer queue has a ThinPrint .print Client installed which receives the EMF data from the ThinPrint Port, decompresses it and moves it into the correct printer queue for rendering and printing.

Should the receiving printer queue reside on the same computer as the ThinPrint Output Gateway queue then the EMF data can be transferred directly without ThinPrint Port or ThinPrint Client. This technology is called V-Layer printing. It allows print servers to render print jobs without printer drivers being copied throughout the IT landscape when the printer share is picked up. The shared printer is always a ThinPrint Output Gateway printer.

The ThinPrint Output Gateway driver is able to automatically import the standard printer settings from the native printer queue it is configured to print to. This import is done by the ThinPrint AutoConnect service and includes paper formats, tray information, color capabilities of the printer and supported resolutions. Besides choosing from the imported options, the user can also set the page orientation, the number of copies, choose between long edge and short edge duplex, and enable a preview to set printer specific features on the client side of a remote desktop session. The administrator is able to set the printing defaults for all of these settings and specify the level of compression which ranges between 60%-99% data reduction depending on document content and application used for printing.

All printer-specific features that are not configurable via the ThinPrint Output Gateway property tabs can be set up on the native printer queue. This is likely to be the user, in the case of locally attached session printers and an administrator, in the case that print servers are in use.

More technical descriptions can be found here:

• The ThinPrint .print Product Family
• .print on the server, the network and the client
• Best practices
• How does ThinPrint .print help me with...