PDF dimension in FFPM 9

[JavierM-Xerox]

Per - very good and thorough answer. I would like to add a little more:

#2 - Yep - this is a feature reqyest. That said, you can achieve this today by using the External component with a CLI email client. You can configure presets to email individual people (and use them in specific workflows) or you can use variables to pass the name and email of the recipient (and any other email content).

#3 - Can you elaborate a little more on your use of fail branches?

#4 - I think Per gave a pretty good answer. Did he answer your question? If not, can you elaborate on the scenario?

Javier

[PerF-Xerox]

1. If you would like to send Color jobs one way and B&W jobs another way in a workflow you could use the Preflight tool. In Acrobat you can find a default Preflight check which checks the number of plates generated. If it is more than one Plate you can set this to report an error. In the FF Core workflow you insert a Route Component after the Preflight and route the jobs by the Preflight Result. You will now route sucess jobs (B&W) one way and all other jobs the other way.

2. This sound like Feature request.

3. The answer is partly the same answer as for the question number 1. Use the Route component after a Preflight component and route by Preflight result (Job Property/Workflow/Preflight result). Another way to do it is to set the Preflight Component to Pause the job and wait for you to make a decision. If you let the job pass through the workflow you can always Resubmit the job to another different workflow to fix the document. You Resubmit within the Job Management window. You can always have a Save component to save error files to a folder to have them fixed manually if needed.

4. You have to decide upfront how you would like the files to look like after they have passed through a workflow. There are many places where you can let the workflow decide and fix your files based on rules or the the original document. You normally don’t need to have a manual preview and correct files. Look closer on the Rotate, Scale and Imposition and you will see that there are big news compared to Process Manager on how to handle decissions. All of thoose can do selections based on Page range, Rotation and Size. Don’t forget to check out the Route component which can always ruote your files based on the things you ask for, like for example Document properties (Number of pages, Rotation, size) Metadata (Keyword, Author) or Job Name. In FF Core you don’t have any limitation of how many Route rules to use in a workflow.

Ways to help you analyse workflow errors: 

a) To help with analysing workflows you can use the Save component on different places in the workflow. Name them so you can follow where in the workflow the file was saved.

b) Test each Job Route or Split component separatly before putting them into a workflow. Always have a workflow for testing of components.

c) Check the job properties. If there is a Imposition used the name of the Imposition Preset will be written. If there is Printer you will see the name of the Printer Destination.

d) Build the workflow bit by bit. Do not build a complex workflow and then start testing and trying to find out why it might not work.

Hope this will help you build your workflow.

[ChrisBeech]

Thanks for the response. It confirms my fear that the variables that the process nodes can access are not exposed to the user. Unfortunately from what I can see in Core thus far I can access the variables I need, but am lacking the other functionalities required to completely define the workflow required. I can achieve everything I need to in PM9 witht the exception of retrieveing the finished page dimensions after all steps of the workflow. 

In no particular order these are the items I am struggling without for this application:

1. Abiity to route files based on Colour or B&W attributes of the file as a whole

2. Node based notifications to non-admin and non-users

3. Lack of Fail branches

4. Review of page orientation and page sizes within a document and route or correct based on results

I struggle as well without detailed information on why a job fails when trying to define a workflow or when files process. Being able to visually see the node that a file failed in can help diagnose what the issue is. Seeing a reported error after adding an Optimize node to a workflow reporting "The document failed with 1 errors" makes it a challenge to diagnose which setting within the node is causing the failure. 

[JavierM-Xerox]

FFCore supports additional variables that are not available in PM9. The PM9 MAX documentation lists all available variables - including the ones retrieved from the job files themselves.

[ChrisBeech]

I love the ability to retieve addition variables from files processing through Core, but unfortunately am missing features to deploy my most recent task. I've been experimenting, and hoping that someone may know whether additional variables are available in PM9 that can be used. 

In Core I can name a file like this: $FFwfjob.jobName$_$FFwfdoc.pages$_$FFwfdoc.pdfPageWidth$_$FFwfdoc.pdfPageHeight$.pdf

This allows me to include things like PDF dimensions into the filename. 

In PM9 I can see the values are available as they can be used in the conditional node, by can't find any syntax to be able to be able to use the values in the filename. Do these variables exist in the older version? $FFNumber of Pages$ does, but what of the others?

Any help would be appreciated.