LPR printing via the external component

[Hans995496-XRXL]

FreeFlow Core v6.x now includes LPR capability via the Print Node.

However, the 'v2' scripts included with this post should address the issue identified by adding the $FFwfJob.Id$ parameter.

Required External Process Node Parameter requirement and order is as follows: "$FFin$" "$FFout$" "$FFxpf$" "$FFwfJob.Id$" "$FFwfJob.jobName$" "ServerNameOrIPAddress" "QueueName" Comments are included in the scripts. Download the scripts and rename txt extension to bat.

[JavierM-Xerox]

I would assume you could work around that by passing the FFC Job ID and then using it to define var1.

[StefanT-Xerox]

I found an issue with this. All VIPP jobs are named "temp" in the system, so when using the variable in the batch file 

set var1=%~n1-print.pdf)

to get the file name without the path, then all VIPP jobs will be named temp-print.pdf. Immediately after the file is printed using lpr, the file is deleted

del /Q "%var1%"

This will work as long as there is one VIPP job at a time processed, printed and deleted, but when more than one VIPP jobb at a time is processed, printed and deleted, the system is confused because all files processed at the same time all want to be named "temp".

Stefan

[Hans995496-XRXL]

By copying the PDF to a working location, the path to the file can be eliminated, allowing you to overcome the character limit. Attached to this response are two scripts that copy the PDF to the working location. One script will prepend the XPF job ticket to the PDF for FFOM and FFPS workflows. The other script does not include the XPF for workflows that do not support the Xerox Job Ticket. Additionally, these scripts allow the Printer and Queue to be defined as External Node parameters, making the scripts more robust. Required External Process Node Parameter requirement and order is as follows: "$FFin$" "$FFxpf$" "$FFwfJob.jobName$" "ServerNameOrIPAddress" "QueueName" Comments are included in the scripts. Download the scripts and rename txt extension to bat.

[S_Cini]

I am having issues with this method.
Currently running 4.0.3.1 and when I try to submit a file this is the result in stdout.log

<stdout 15/03/2016 3:28:25 PM>

C:\Xerox\FreeFlow\Core\00000000-0000-0000-0000-000000000000\Data\Scripts>lpr.exe -S 13.199.33.83 -P HOLD -o l "C:\Xerox\FreeFlow\Core\00000000-0000-0000-0000-000000000000\Platform\Spool\e3b7366c-7ac7-47d9-a91e-caeb61860784\contourpath.pdf"
Error: could not open C:\Xerox\FreeFlow\Core\00000000-0000-0000-0000-000000000000\Platform\Spool\e3b7366c-7ac7-47d9-a91e-caeb61860784\contourpath.pdf for reading.

</stdout>

running the above manually at cmd prompt gives the same error.

manually copying the contourpath.pdf to "C:\Xerox\FreeFlow\Core\00000000-0000-0000-0000-000000000000\" and editing the command to suit path allows lpr to succesfully run.

Is there a limitation to the path character length or am I missing something?

Can the spool folder location be modified via a settings file?

I should add that FFC is being run from a Windows 10 box.

[JyriS-Xerox]

Unfortunately we have no way of adding the number of copies switch in the LPR – comes from a Windows limitation.

Either you abend the job ticket in the front of the file or use FFPM-APP.

[RenzoS-Xerox]

Hi guys, what about the number of copies to be printed (value inherited from MAX)?

Does LPR be able to send to the printer also this info/variable?

Or this info is lost using LPR command?

Regards

Renzo

[JavierM-Xerox]

Extending this example to show how to get a job with an XPIF print ticket submitted to either FreeFlow Output Manager or FreeFlow Print Server.

The batch file that will do the LPR print submission needs to be extended to concatenate the XPIF print ticket and the PDF into a single file.

REM Get the filename without the path
set var1=%~n1-print.pdf

REM Concatenate XPIF + PDF as required by FFOM and FFPS
copy /B %2+%1 "%var1%"

REM LPR job
C:\Windows\System32\lpr.exe -S 13.241.28.68 -P queue -J %2 "-o l" "%var1%"

 Note: I had to put the full path to lpr.exe. I believe that's a difference between Windows 2008 and 2012 server.

Also, the parameters in the External Process preset need to include the path to the XPIF file.

The above will allow printing of ticketed jobs from FreeFlow Core to FreeFlow Output Manager and FreeFlow Print Server DFEs.

[JavierM-Xerox]

CLI LPR printing requires use of the LPR Print Monitor in windows. This is enabled via the Add Roles and Features Wizzard:

Once that's doen you should be able to type LPR in a Command Prompt and see the CLI Help for CLI LPR Printing.

The external node in v4 SP1 was changed so that it no longer requires moving of the input file (aka $FFin$) to the expected folder. This post assumes that functionality.

Once the LPR Port Monitor is working, two things are needed:

1. A batch file for printing (invoking LPR directly from the external component will give you a job name that's a very long random string)
2. A properly configured external node

I've enclsosed the batch file. These are the contents:

lpr.exe -S 13.123.253.150 -P tom_HOLD -J %2 "-o l" %1

Used LPR options:

-S is the printer

-P is the queue name

-J is the job name

"-o l" tells LPR you are printing a binary file

%1 and %2 are the parameters from the external process node:

When FFCore executes a script via the external components it will archive stdout and stderr iin the External Process Status subfolder in the Scripts folder within the sandbox. These files contain the content that would otherwise display in the command prompt.