How to print when the printer name comes from a local variable?

Hello, to print my documents, I receive a spool file where the printer name is specified as part of the text.

I was able to parse the incoming spool file and assign the printer name (which matches a server’s local printer name) to a local variable.

At the end of the workflow processing, I’d like to send the output to a WinPrint or LPR printer queue, and use my local variable %{printer} to select the actual queue name.

As I won’t use the Connect’s output_preset printer definition, my Create Output step in the workflow reads “Output Management = Through PlanetPress Workflow”, so that my PDF output produced in that step is taken back from the server for further processing in the following steps, instead of being sent directly to the printer (I cannot select a dynamic printer name on the Create Output step).

So, after the Create Output step as explained above, I next have a Print Using Windows Driver step, where I can use my variable to specify the final printer destination.

The printer selection works with WinPrint, but I cannot get the right results from all the printers, as some of them cannot natively interpret the PDF document being sent, which is printed as text, like “%PDF 1.5…”.

So I tried to use the Printer Queue Output step instead. In this case I have to select a Printer Queue defined in the workflow. No issue to configure this step as a passthrough step.

The Printer Queue definition was defined with Server Address=localhost and Queue Name = ${printer}. In fact, my printers are all shared with their own name, so they should be accessible from localhost.

The fact is that all this doesn’t work, so I am forced to produce my PDF file, send it to a folder and than use a separate process to print it to the printer, even if I have to use part of the filename to pass the printer information to the printing process.

I’d like to use a more elegant approach, which I suppose it’s possible with PlanetPress, and also because I need it for another process which is supposed to print plain text file without any template definition (pure “LinePrinter mode”) on a dynamicly named printer.

Thanks for any info/suggestion,

Marco

Hi Marco,

What about producing PostScript instead of PDF files in your output? Assuming your printers are all postscript, they can all natively use this format, can’t they? Just a passthrough should work just as well as when you did it with PDF.

If not (say, some of them are PCL), you could put a condition before the output creation task and, depending on which printer you’re sending to, use one or the other output presets (PCL or PostScript).

Hi Evie and thanks a lot for your quick answer!

My printer doesn’t support PostScript, but it does support PCL. Unfortunately, the text rendered with PCL si correct, but the graphics (lines, barcodes, etc…) comes out totally wrong. I cannot explain why.

For now I’m reverting to a solution where I produce a PDF file, store it into a temp. folder, then use another process to pick it up and print it. That works, but I don’t like it.

In addition, since I don’t know in advance which printer I need to print to, between the two processes I need to establish a way to pass the “printer” information from the 1st to the 2nd process. I put the printer name as part of the filename, and still I don’t like this.

So, all this only because I cannot get proper results when producing my output as PDF and directly send it to a printer, which should be the most common things a user could do with PP, I imagine.

But I am a newby with this application and I’m using it since just 1 month or so. Still testing it.

Thanks,

Marco

Hello Marco!,

If your printer accepts pdf files via lpr then I would configure it that way. Do note that this may eat more bandwith since you are sending the file AS is over the network to the Printer ‘print controller’.

How it works is: You create a lpr queue type in your printers ip-address then type in a queue name example “auto” and then define the file type which should be binary.

After this verify it works and if your printer accepts naitive pdf printing withhout it having to be deciphered to pcl language then you will be golden.

Let me know if this helps.