I am curious about the LPD printing input on the workflow option. How does this setup work exactly? In my search on the topic I’m not finding much information. I did find this bit from 2014 though…
This warning is just that: a warning, and doesn’t mean that it can’t work. But usually, LPD queues are a single word, and underscores are used instead of spaces. Also, the LPD Input will create it’s own LPD queue on your network, it won’t use a Windows printer queue, so you don’t necessarely need to use “PlanetPress Printer”.
After starting up the LPD print queue, I’m not seeing that the service created any LPD Print Queue on it’s own so I’m assuming I have to configure this myself. I attempted to do that creating a printer using an TPC/IP port and the name keyed in the LPD Printer input (on the same server as workflow), but can’t seem to get it to work.
One of the threads mentions that windows LPD service has to be off or it will interfere with PP’s LPD server. I have the LPD Service off, and PP’s LPD service running.
I know I’m probably just not understanding the configuration correctly, so any direction anyone might be able to provide would be most appreciated. Thank you in advance:
Links I’ve tried to follow (but are old, not sure if still relevant):
Asuming you are working in a Windows environment where the Server is a Windows OS and the client systems are also Windows Oses, the below guide lists the steps required to set up a LPD Input process for the first time in a PlanetPress or PReS Connect workflow system. These steps include creating a shared TCP/IP printer queue on the server and installing it on client systems. In addition, it will also be necessary to enable windows LPR service on client system to enable them to send PostScript spools to the server via TCP/IP.
Generally, you will need a system which can LPR to the server.
Before proceeding with the steps below, it is recommended to back up the PlanetPress or PReS Workflow configuration and its associated resources.
Creating a TCP/IP Shared Printer on the PlanetPress\PReS Workflow Server
The first step is to create a shared TCP/IP printer queue on the PlanetPress or PReS Workflow server. If one already exists on the system, skip this part
Go to Windows Control Panel > All Control Panel Items >Devices and Printers.
Click on Add a printer, then click on “The printer that I want isn’t listed”.
On the next Window, select “Add a local printer or network printer with manual settings” and hit Next.
Choose a printer port
a. If a TCP/IP port already exists, choose “Use an existing port” and select the TCP/IP port from the dropdown list and go to step 8.
b. Otherwise, choose “Create a new port” and select “Standard TCP/IP Port” and click Next.
Enter the hostname or IP address of the PlanetPress server and hit Next
On the “Additional port information” window, select “Custom” as the “Device Type” and click on “Settings” button.
Configure the new printers TCP/IP port as seen below and click OK to save.
On the next windows, select the Objectif Lune driver or any other PostScript driver and click Next to follow onscreen instructions for naming and sharing the printer. Then, give the printer a name and share it giving it a share name which will be used to install the printer on client systems.
Installing the shared printer queue on client systems
To install the above printer queue on client systems:
Log into each client system with a local administrator account
Open Windows Explorer and go to \PlanetPressServer\printername[Ex: \Server01\PlanetPressPrinter]. You may be required to authenticate using valid logon credentials to the PlanetPress or PReS Server.
Then click on “Install driver” to install the printer.
Enabling the Windows LPD and LPR Services on client systems
It is now necessary to enable a mechanism by which the newly installed printer on client systems will send the PostScript spools to the PlanetPress or PReS Workflow server via TCP/IP.
This is achieved by using or enabling the Windows LPR and LPD services. To enable these services on client systems:
Open Windows Control Panel > All Control Panel Items >Programs and Features
Click on “Turn Windows features on or off”.
Expand the “Print and Document Services” node.
Select the “LPD Print Service” and “LPR Port Monitor” options and click OK to save.
Now go to Control Panel > All Control Panel Items > Administrative Tools > Services and ensure that the “LPD Service” has been installed and is started.
Creating the PLD Input Process
To create a LPD Input process:
Simply start the process with the LPD Input plugin using the LPD queue name specified in the TCP/IP printer’s port configuration.
Start the PlanetPress or PReS Workflow LPD Server service
Now, from a client system, simply print to the shared printer queue installed on the client system from any application. The spool will be sent to the PlanetPress or PReS Workflow server and can be seen in the LPD Server log.
Add a Create PDF task and set its Document to passthrough (default option)
End your process with a Send To Folder task that saves the resulting PDF to any folder you like.
That’s it. Now all you need is an LPR system to send a PostScript file to the myLPDQueue printer queue and the process will convert it to PDF. If you don’t have a LPR-ready system (like a Unix/Linux server, for instance), you can create a second process that will do exactly that, in order to test the LPD queue:
Create a new printer queue ?named PrintTo_myLPDQueue and set the parameters as follows:
End the process with a Printer Queue output that points to the PrintTo_myLPDQueue queue
Now when that second process runs, it will send that basic PostScript file to the myLPDQueue queue, which is monitored by your first process. That first process will retrieve the PS job and convert it to PDF (containing a bunch of “hello world”).
The first part explains how to create an LPD printer queue using the Windows printing subsystem. If you go that route, you need a WinQueue Input task to capture jobs, and it may have gone through a printer driver (or not, your mileage may vary).
The second part explains how to use Workflow’s own LPD server. This one does not rely on Windows and usually provides better control if the print stream is pre-formatted as there are less chances of getting a printer driver involved (your mileage may vary, again).
Both are mutually exclusive, first of all because both LPD servers will want to live on the same standard TCP port (port 515).
There is no general usage rule whether to use one or the other. The LPD server was initially developed in times when dinosaurs ruled the Earth and Windows 95/98 didn’t have a built-in LPD server. It has stayed there since, for backward compatibility and for convenience as getting the LPD server in Windows is usually a bit of a hassle because it requires some setup steps whereas in Workflow you only need to put a name.
We usually get a lot of requests from customers who want to print jobs to specific printer queues via LPR and not always get a PDF at the end… You are correct printing via LPR can vary hugely depending on the specific end users setup and requirements; however in my experience I found that most users understood the principle once they knew how to get this to work in a Windows environment and from there they can then go on to tailor the solution\setup to their exact needs. All you really need here is a system which can send jobs to the PlanetPress LPD server via LPR whether it is from a Linux, Unix system or from Windows (using LPR command\protocl) or even using a Windows printer queue (using a PS driver) pointing at the PlanetPress Server through port 515.
You all have once again gone above and beyond in terms of your ability to offer assistance. I haven’t responded right way because I’ve been plugging away trying to make sure I can offer a best solution, but I think I’ve finally figured out where my hang up was.
Thank each of you for your input and for being awesome!
I can’t remember the last time I came across such a clear and well written guide :-). The third part about activating the LPR service on users PCs is what we were missing to configure LPD printing successfully. We ended up using the winqueue input where we had to keep all virtual printers paused and it has often caused confusion leading to failed jobs when users would un-pause the virtual queues. We have tried your steps this morning and for the first time in 3 years we are now able to receive users documents through the LPD input plugin without having to pause the printers.
This is undoubtedly one of the best support forums out there and I continue to be amazed by the quality of the detailed responses on this platform.
…
