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.
I found an issue with this. All VIPP jobs are named "temp" in the system, so when using the variable in the batch file
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".
I am having issues with this method.
Currently running 188.8.131.52 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 184.108.40.206 -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.
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.
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.
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?
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 220.127.116.11 -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.
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:
I've enclsosed the batch file. These are the contents:
lpr.exe -S 18.104.22.168 -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.