Make workflows dynamic with variables

Most checks you want to run on PDF documents are generic: colors have to be correct, image resolution needs to be sufficient, dangerous PDF constructs must not be present and so on. In those cases it is perfectly possible to create a single preflight profile that is used for many different products or in many different workflows.
But sometimes checks are very specific and cannot easily be shared. A good example of such a case comes up if you want to check job dimensions (width and height). Those dimensions could very well be different for every job and that means that you need to now duplicate that single profile for each product and insert a specific size check… That doesn’t sound like the best idea…
Luckily pdfToolbox and pdfaPilot support variables that can make the preflight dynamic (different for each product or even each checked PDF file). And the best news? They’re easy to use!

A static (regular) size check

Checking the size (dimensions) of a PDF document boils down to checking the height and width of a page box, typically the trimbox, which gives the size for the final piece. Such a check may look like this.
 
Figure 1: a preflight check for the height and width of the trimbox

The check tests the width and height of the trimbox, in this example taking orientation into account (in other words, landscape and portrait are not interchangeable for the purposes of this check).

A dynamic (variable) size check

If you look at the window that defines the static check, you’ll see a number of orange icons. Each of those allows inserting a variable into that particular check property. When clicked, they bring up the variable editor.


Figure 2: the variable editor

To define a variable in a check or fix, pdfToolbox needs three pieces of information:

  • Label: this is shown when the check or fix is executed in pdfToolbox Desktop.
  • Default value: the value used when nothing special is done during execution of the check or fix.
  • Internal Name: the variable name that can be used in pdfToolbox Server, CLI or SDK to modify what value will actually be used by the check or fix.

To make our check fully dynamic, we have to input variables for the width and height of the trimbox.

Figure 3: a dynamic check showing variables in use

The more cryptic value for the width and height properties make it clear that there is indeed a variable defined for each of those properties. That’s all we have to do in our check to make it dynamic.

Using dynamic profiles

pdfToolbox Server

If a preflight profile contains at least one check or fix that contains variables, it’s called a dynamic preflight profile. Such profiles can be selected in pdfToolbox Server just as you would a regular profile. But then you can modify what values will be used by adding additional CLI commands in the pdfToolbox Server job window.


Figure 4: the pdfToolbox Server job window
 
While the above pdfToolbox Server job looks perfectly normal, we did add additional CLI parameters to setup our variables. For each variable, we add something in the format:

--setvariable=<variable_name>:<new value>

  • Variable name is the symbolic name for the variable as you defined it in the check or fix.
  • New value is the value you want pdfToolbox to use during preflight.

As you can see this allows you to take a variable preflight profile and configure different jobs, each of which will perform a different preflight based on the “setvariable” commands you add in the job definition.

pdfToolbox CLI and pdfToolbox SDK

You can actually go further still when using pdfToolbox CLI or pdfToolbox SDK. Because there you issue commands to preflight each file, you can actually modify how the preflight should be done for each individual preflight.
This is great if you have a web portal that can tell you what the customer ordered and if you can modify each preflight to match the checks to actually what the customer ordered.

Possibilities of variables

Variables can be added to checks and fixes. The only limitation is that the property of the check or fix needs to have that little orange button next to it in order to let you define a variable.
But it is also possible to select a check or fix in a profile and setup a variable that will act like a switch: set it to “1” and the check or fix is executed during preflight, set it to “0” and it’s not executed. This allows you to build profiles that contain optional checks or fixes and simply by setting the value for the variables you used to the correct values ensure that the checks and fixes are or are not executed…

Questions?

You can read much more about all of the products mentioned in the product pages on the web site. Or simply contact us for a personalized demo or to ask more in-depth questions.