Standard ThinPrint scenario
In a normal setting, ThinPrint Engine is installed on a remote desktop (terminal server or virtual desktop), or on a central print server. When a user initiates a print job, ThinPrint Engine compresses and encrypts the print data and streams it (in packets of some KB) across a preset bandwidth to the ThinPrint Client.
ThinPrint Client decompresses and decrypts the print data and forwards it to the correct print interface. If ThinPrint Output Gateway (Driver Free Printing) is used on the server, rather than an original printer driver, ThinPrint Client Windows feeds the print data into the Windows print process so that the data is rendered on the client machine with the original printer driver.
Printing via DMZ and into masked networks
So that the ThinPrint Client does not have to be installed on every end device in a remote office, it is sufficient for it to be installed on a local print server. Alternatively the ThinPrint Hub can be used. The ThinPrint Client installed there receives all print data, decompresses and decrypts it and then distributes it conventionally through the office network. Here again, NAT poses no problem as the Connection Service resolves any NAT related issues: The ThinPrint Client connects to the Connection Service, therefore establishing a connection through which print jobs can be sent despite NAT.
This scenario can be used beyond just Windows environments. All required printers are installed in V-Layer mode on a central print server. With these printers, it is possible to print in any Unix, SAP, AS/400 or iSeries system. The ThinPrint Engine installed on the central print server compresses and encrypts the print data and sends it over controlled bandwidth to the ThinPrint Client.
In addition, the printers, including Connection Service Ports and drivers can be created on the central print server, using the Management Services.
