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
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:
- 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…