ThinPrint .print on the Server, the Network and the Client
In ThinPrint’s terminology the server is always the machine where the .print Engine installed. In most cases it is a terminal server or a print server but also a physical or virtual PC can be the server in this context. With the exception of the .print Engine for AS400 the print processing of all .print Engines is completely integrated into the Microsoft Windows print subsystem. This not only maximizes compatibility and scalability but also keeps printing with ThinPrint .print simple which in return guarantees stability.
Knowing how the Microsoft Windows print subsystem works helps understanding the technology of ThinPrint .print. In a somewhat simplified way the following happens when a user prints from an application running on a Microsoft Windows server or desktop operating system:
| 1. |
The printing application uses the GDI engine of the Microsoft Windows operating system to create a transcript of the information to be printed. To do so the GDI engine communicates with the selected printer driver to apply correct information regarding paper size, resolution, color depth, etc to the print job. The format of this transcript is called Enhanced Metafile (EMF). It is printer independent and compatible between all Microsoft Windows print subsystems.* |
| |
|
| 2. |
The Enhanced Metafile is then handed over to the print subsystem. The spooler client (winspool.drv) is the component that receives the EMF data. It forwards the information to the spooler server (spoolsv.exe) which again provides the spooler router (spoolss.dll) with it. |
| |
|
| 3. |
The spooler router has to determine which print provider to use for further processing. This is based on the selected printer queue. If the printer queue is installed locally then the local print provider takes over. For printer queues shared on other computers, one of the installed remote print providers, the LANMan Print Provider, is being used.** Since the remote print provider forwards all further print processing to the spooler client of the remote Microsoft Windows-based computer we can concentrate on the local print provider because it will also be the local print provider on the remote system that handles the next steps of printing. |
* Some applications create the print job directly in connection with the printer driver without delivering EMF data to the print subsystem. This is rare but seen with custom applications and older applications.
** The LANMan Print Provider is used for printing to printer shares on other Microsoft Windows based computers. The Internet Print Provider handles communication for IPP printers. Other Print Providers can be installed.
| 4. |
The local print provider analyzes the data it received from the router. Should the format be EMF the print data is forwarded to the print processor of the selected printer which uses the GDI engine of the operating system to convert the EMF data into a format the printer is able to process. All print data that is not in EMF format is called RAW data. That includes all Postscript and PCL language versions as well as other proprietary formats. |
| |
|
| 5. |
After the print processor completes the conversion from EMF to RAW it forwards the information to the spool client again and the steps described above are repeated with the exception that now the local print provider detects that the print data is not in EMF format and directs it to the print monitor instead of the print processor. |
| |
|
| 6. |
The print monitor contains the printer port. This is the component transmitting the print data to the printer. Common printer ports are called Printer Port (LPTx), Serial Port (COMx), Print to File (FILE:) or Standard TCP/IP Port (IP_xxx.xxx.xxx.xxx). |
It is well known that printer drivers can be added to the Microsoft Windows print subsystem. The same is the case for the Print Provider, the Print Processor and the Print Monitor***. ThinPrint .print adds three components - a printer port, a printer driver and a print processor - to the existing print environment without modifying or interfering with any existing configuration. This is an important requirement for a gradual transition from an existing print environment to a ThinPrint .print environment.
*** In fact many USB based printers and especially multi-function printers make use of adding print processors and print monitors to the print subsystem - which by the way is one of the reasons why the life of the print administrator of a terminal server farm is tough.
The majority of benefits the .print Engine provides come from ThinPrint’s own printer port. This printer port named ThinPrint Port receives the print data, compresses it and it sends over the network via TCP/IP, LPD, RDP or ICA to the correct .print Client or LPR device. The ThinPrint Port performs these steps on small packages of the print job to accelerate the printing. This streaming technology also balances the resource requirements of server, network and client which reduces unwanted spikes in CPU, memory and hard drive activity.
Designing the ThinPrint Port after Microsoft’s specifications for printer ports allows the administrator to use the same options and flexibility that standard Microsoft printer ports provide. The administrator decides how many instances of the ThinPrint Port are being created, how many printer queues are attached to each ThinPrint Port and also how many ThinPrint Ports are used by each printer queue.
Since each ThinPrint Port is configured independently, the optimum configuration for bandwidth control, compression and transmission protocol can be set up for each printer individually. In reality, however, administrators save configuration time by grouping printers based on type or connectivity and configuring ThinPrint Ports after the group requirements. That way a single printer port configuration might overcome print-related challenges for 80% of the printer base; another one takes care of 15% and maybe a third or fourth configuration brings the configuration to 100% - maximum benefits.
A second ThinPrint .print Engine component directly involved in printing is ThinPrint’s universal printer driver - the ThinPrint Output Gateway. It is required to eliminate the need for printer drivers on servers and desktops.
The ThinPrint Output Gateway has the appearance of a printer driver to provide users with a GUI to configure printer settings and to provide applications with all required information to create a print job via the GDI engine of the operating system. However, behind the interfaces the ThinPrint Output Gateway differs completely from typical printer drivers. Instead of rendering a print job from EMF format to RAW data the ThinPrint Output Gateway keeps the EMF format and ensures that the Print Provider forwards it directly to the printer port. Being able to read and interpret the EMF format also allows the ThinPrint Output Gateway to optimize compression by applying the best compression algorithm for each element of the print job.
EMF data has to be converted to printer specific RAW data somewhere for a printer to create a printout. The great thing about the ThinPrint Output Gateway is that the administrator can decide where on the network the best place for this rendering is. This freedom of choice offers the following benefits:
- Simplified printer driver management,
- Higher utilization of computing resources,
- Savings in memory and CPU cycles,
- Reduction of negative performance spikes on terminal servers and virtual desktop servers and
- Avoidance of print device specific dependencies on servers providing applications to users.
As long as the machine designated to render the print job is based on a Microsoft Windows server or desktop operating system it can be used to complete the rendering process. This could be a client PC, a central print server at the data center or a print server at a remote office.
A print job, sent from the ThinPrint Port crosses the network in packages. The interval between each data package and the size of each data package is based on the bandwidth limit that is set for the ThinPrint Port sending the data. A high bandwidth limit means short intervals and larger packages and a small bandwidth limit means longer intervals and smaller packages. Turning off bandwidth control leads to the ThinPrint Port sending packages as soon as they become available.
In connection with a .print Client the print data is also compressed while being transmitted, unless the protocol of the ThinPrint Port is set to LPD. The .print Client decompresses the data and streams it into a printer queue on the client side. These core functions are provided by all .print Clients which could be a piece of software running as executable in the user’s context, a service running in the background, a Dynamic Link Library started and stopped with an RDP or ICA session or component of the firmware of an appliance, thin client or printer.
All current .print Clients are also capable of receiving encrypted print data, communicating the local print configuration to the .print Engine to automatically configure server side printer objects with the settings of their client-side counter parts and reversing the direction of communication with the .print Engine. While encryption and communicating information about client-side printers are fairly straight forward, the reversal of communication deserves some additional explaining. Normally the ThinPrint Port opens a socket connection to the .print Client when a print job is supposed to be printed. This works fine with RDP/ICA protocol. It also works without any problems when TCP/IP is used as long as the client can be reached via TCP/IP from the server. If that is not the case due to firewall restrictions or a NAT’ed network then the .print environment can be set up so that the .print Client and the ThinPrint Port open connections to a service called Connected Gateway which is located in a network segment that can be reached via TCP/IP by the server and the clients. The Connected Gateway ensures that traffic is routed correctly between the connections ThinPrint Port to Connected Gateway and .print Client to Connected Gateway by using matching IDs between .print Client and printer queue on the server side.
The one feature only .print Clients for Microsoft Windows operating systems support is receiving print data in EMF format and moving it into the print subsystem for rendering to RAW format. Since EMF is a Microsoft Windows specific format it requires a Microsoft Windows print subsystem to be processed. In case the client machine does not have such a subsystem, another machine can usually be dedicated for print job rendering. The .print Client for Microsoft Windows acts like an application attempting to print and sends the unrendered EMF print data it received from the ThinPrint Port into the correct printer queue the same way the application on the server side sent EMF data to the ThinPrint Output Gateway printer queue initially. The client-side print provider recognizes the print format being EMF and forwards it to the print processor of a client printer queue and the native printer driver performs rendering before a local printer port sends the rendered (RAW) data to the printer.****
**** This includes scenarios in which a client computer prints via a local print server to a network printer.
Developing ThinPrint .print in individual modules that work well together as part of the Windows print subsystem allows for maximum flexibility in designing the printing environment. Any number of printer queues can be attached to any number of ThinPrint Ports which can print to any number of client side printers, configured on a variety of client devices. The determination of where a print job is to be sent to is based on information from the name of the printer queue. It contains either the host name or the IP address of the client for TCP/IP or LPD printing or the user name if the print protocol is set to Virtual Channel (ICA/RDP) and can also contain an ID which corresponds to a printer queue on the client side.*****
***** The .print Engine includes the ThinPrint AutoConnect service which is used to automatically create printer queues with the correct naming convention. On machines hosting user sessions this service is usually set up to create printer queues when a user logs-on or reconnects to a session and to delete the printer queues when a user logs-off or disconnects from a session. On central print servers ThinPrint AutoConnect can be used to import printer queue configurations from remote print servers to enable .print based printing to them.
More technical descriptions can be found here: