Line Printer Daemon
Some converters and gateways of the convert4print system have a so-called RAW interface on the input side. This means that a program can establish a direct, bidirectional TCP/IP connection to the converter or gateway via which the print data is transferred and printer statuses are reported back according to a defined protocol, e.g. PJL. For Windows computers, but also many host systems such as i5/OS or z/OS, this type of transmission is a good solution because of its bidirectionality.
Systems such as Unix, AIX, Linux or MAC-OS X also offer RAW interfaces, but these are the exception and require additional administration effort. The standard solution of these systems for the transfer of print data is the use of the LPR (Line Printer Requester) / LPD (Line Printer Daemon) protocol. Some ERP systems, such as SAP, also use this protocol directly from the application.
A special gateway is intended for such applications: the line printer daemon. In principle, its task is to wait on the network under port 515 for connection requests and to forward the transferred data to the converters or gateways for processing by convert4print. The LPR part of the protocol runs on the printing computer and the LPD part of the protocol runs in convert4print.
The great advantage of not supporting LPD directly in the converter, but controlling it via a separate gateway, is that the spool system that is normally placed behind an LPD server can actually be implemented.
There are two possible scenarios for using the line printer daemon: First, the transferred data are spool files that can be processed directly by the converter or gateway. They can be forwarded directly.
In the second case, data formats are transferred that are not directly usable. Here the line-printer daemon offers the possibility to process the print data with the help of external scripts or programs before they are forwarded to the converter or the gateway.
One use case for this scenario is, for example, when Java applications deliver PDF files as print data. The line printer daemon writes the received data to a file and transfers it to Adobe Reader for printing. Adobe Reader then forwards the print data to the required convert4print converter or gateway.
Since the LPR/LPD protocol is not bidirectional, no status messages regarding the print job are returned to the printing application. Since the line printer daemon is a fully-fledged spool system, as is usual in these cases, the application does not even know if and when printing took place at all.
For each converter or gateway, a so-called queue is created by the line printer daemon, in which print jobs are collected even if the corresponding printer is not ready for operation. This automatically decouples the time between the application and the print process - the application is not slowed down, even if it does not print via a spool system.
Of course, the fact that the line printer daemon always only listens on port 515 does not mean that only one print file can be transferred at a time. Currently, 16 simultaneously incoming and up to 256 outgoing connections are possible - assuming correspondingly powerful hardware and a Windows server version.
If the printing computer is nevertheless interested in the status of a print job, the line-printer daemon also supports the Windows/Unix/Linux command lpq, with which status information can be read back.
