Solid Technology Embedded In Intuitive Products

callas software, developer of the preflight technology used in Adobe® Acrobat®,
has a range of own desktop and server products allowing users to either
interactively or automatically process PDF files.

callas software’s pdfToolbox product range is aimed at the print and publishing market,
its pdfaPilot products are aimed at bringing reliable PDF-based long-term archiving
to a variety of industries.

The pdfToolbox product range has revolutionized the way of handling PDFs for print.
Instead of having to look for errors, dig through reports and edit individual objects,
it just fixes files for the production process they are intended for and uses
breakthrough visualizer technology to highlight any remaining potential problems.

callas software has laid the foundation of porting that same philosophy
to document archiving with the callas pdfaPilot product range.

Catch the issues early - Preflight for a trouble-free production

These solutions talk about how to detect the most important problems in PDF documents,
how to report them and how to fix common problems:

• 0. The Basics of Preflight


• 1a. Preflight PDF files


• 1b. Report preflight errors - Preflight reports


• 1c. Visually inspect PDF files


• 1d. Work with color in pdfToolbox

Preflight - What is it?

Preflight is the process of checking your documents to see
they are fit for whatever use you have for them.

Preflight

• is not limited to printed material


• is different for different workflows

When do you preflight?

• in all crucial places of your workflow,


• whenever a big change is made in the workflow,


• as many times as possible, and where it makes sense


• Best practices for preflight:
• when creating native documents


• after generation/export to PDF


• whenever there is a workflow transition:
• if receiving files from the outside


• before sending files to another workflow

Preflight Standards & Profiles

• a standard or specification defines what a PDF should and should not do


• a preflight profile implements such a standard in software to report on:
• information: things you want to know about


• warnings: things that might be a problem


• errors: things that will definitely be a problem

Detect vs fix

• Software tools (such as callas pdfToolbox, callas pdfaPilot or Adobe Preflight) can often:
• detect problems (preflight), and


• fix problems


• Why fix?
• often quicker to fix


• whoever made the file may not know how to fix it


• What should be fixed?
• things that should be fixed


• things that are safe to fix


• things where the severity of the fix is known and manageable


• some things cannot be fixed (e.g. image resolution too low)


• some things should not be fixed automatically,
  but only after close inspection

Use Existing Standards and Profiles for Preflight

PDF quality control or preflight is used to check PDF documents
to make sure they are suitable for use in print, in publishing, in an archive or
whatever other purpose they have.

callas software created its preflight technology to perform such
quality control manually and/or fully automated.

As a testament to the quality and reliability of the callas preflight engine,
it was licensed by Adobe and is used in the Adobe Acrobat Preflight plug-in.
Read on to learn how to preflight your PDF documents in various ways.

It all starts with a profile

The cornerstone of any quality control done with a callas product
is a so-called preflight profile.

A profile is a collection of the checks you want to do on a PDF document
and (optionally) the problems you want to fix while preflighting.

In order to be able to preflight your PDF documents, you will either have to
choose a predefined preflight profile (one included in the product by callas)
or you will need to make your own.

The predefined profiles provided by callas software
fall roughly in the following categories:

• Profiles following PDF standards such as PDF/X, PDF/A, PDF/VT and more.


• Profiles implementing PDF specifications from industry associations
  such as the Ghent Workgroup and PDF/X-Ready.


• Other example and demo profiles.

Figure 1: The pdfToolbox Profile window showing ISO standard profiles

Manual preflight

You can inspect your PDF document manually using
pdfToolbox Desktop or pdfaPilot Desktop.

Both products operate either as a plug-in inside of
Adobe Acrobat or as a standalone application.

Preflighting your documents is as easy as
opening the PDF file you want to check,
selecting the correct preflight profile in the “Profiles” window and
then hitting one of the buttons “Analyze” or “Analyze and fix”.

Figure 2: Preflight results for a PDF/X-1a profile

When performing a manual preflight, the “Result” window pops up and
displays a list of informational items, warnings and errors.

Using watched folders to preflight

In many workflows it is more efficient to organize automated preflight;
instead of opening each PDF individually, a hot folder or watched folder is setup.
Any PDF document dropped in this folder is automatically picked up and preflighted.
The results are moved to predefined folders.

Figure 3: A watched folder setup in pdfToolbox Server to create PDF/X-4 files

Each created job defines an input folder
(the watched folder where PDF files are picked up from)
and output folders for files without errors, files with errors,
files with warnings and so on.
The preflight profile selected in the job defines which
checks and fixes are going to be executed on processed files.

Integrated preflight

Often the most efficient way to preflight PDF files is integrated
into a larger solution such as a delivery portal or web-to-print solution.
callas tools provides both a command-line solution and
a real SDK to support these scenarios.

• Command-line integration

pdfToolbox CLI and pdfaPilot CLI

are command-line applications that can be started from
a terminal or command window, but are typically launched from
the application or script they are integrated with.

These versions of the applications support all of
the preflight capabilities and can automatically generate
detailed reports (in PDF or XML) for further integration.

• Using the SDK

pdfToolbox SDK and pdfaPilot SDK

are solutions providing integration on a library level.

The SDK contains the necessary libraries, headers, documentation and samples to
integrate preflight closely in a C, C++, Java or .Net application.

Integrating preflight using the SDK requires development resources
but does allow for the closest integration in the end.

The purpose of preflight or quality control is to find out
whether a PDF document is suitable for print or archival
(or any other purpose).

To do so you preflight the PDF document with a specific
preflight profile and examine the results.

Classic PDF reports
Comment report, Transparency mask report, and Layer report.

Three forms of PDF reports format preflight results in a fixed layout;
each uses different technology to let you see which objects caused
particular errors or warnings.

These reports are regular PDF documents and can be opened in any PDF viewer
(such as Adobe Acrobat or Apple Preview).
This makes them ideal to be emailed to clients in order to
explain what errors they have to correct.

Overview

Each of these reports optionally begins with an overview page;
this page summarizes information about the preflighted document,
the environment in which it was preflighted and provides
a list of errors and warnings.

Figure 1: The summary page of a preflight report

Comment report

This type of report uses comments (also called annotations)
to highlight the objects causing a particular error.

After the summary page, additional pages are added that are
a copy of the document that was preflighted.

These pages have yellow comments on top of objects
causing warnings and red comments for objects causing errors.

Figure 2: A comment preflight report

Each comment shows both the name and description of the preflight error or
warning that triggered it; as such it makes it easy for clients to see what object
was wrong and why it was wrong.

Transparency mask report

The transparency mask report uses a combination of transparent object
and layers to highlight problem objects in a PDF document.
This means that the report will only work in PDF viewers that support layers
(such as Adobe Acrobat or Adobe Reader) and not in viewers that lack
this support (such as Apple Preview).

Figure 3: Transparency mask preflight report

Layer report

The layer report puts objects with a particular problem on a layer;
this allows toggling layers on and off to see all objects
causing a particular problem.

Because the report also adds background layers,
you can easily see the problem objects on differently colored backgrounds
(which is great to see white objects for example).

The report will only work in PDF viewers that support layers
(such as Adobe Acrobat or Adobe Reader) and not in viewers
that lack this support (such as Apple Preview).

Figure 4: A layer preflight report showing transparent objects
on a differently colored background

Customizable PDF reports

All of the classic PDF reports are static,
in the sense that you cannot change the layout,
colors or text of the preflight reports.

In some environments that is fine, but often it would be nicer to
be able to change some aspects of a preflight report
– especially so if the report is being used for external communication.

The custom PDF report was created specifically to allow you to modify
how the preflight report looks and feels.
This report is based on an HTML template (also using CSS and JavaScript)
and because you can create your own templates, it’s easy to change colors,
modify or add your own logos or artwork and even modify what text is shown.
Always wanted a much simpler preflight report to communicate back to clients?

The custom PDF report is the way to accomplish that…

Figure 5: The default custom PDF report included in pdfToolbox

Figure 6: A custom PDF report based on a modified template

In the modified report shown above logos were changed,
the color of the background elements was changed from
red to purple and various pieces of text were changed as well.
Of course much bigger changes are possible as well as long as
you have some knowledge of HTML and/or JavaScript.

XML reports

PDF reports are great to provide feedback to internal users or external clients,
but when an automated process is involved PDF is typically not perfect.

For precisely that reason pdfToolbox and pdfaPilot have the possibility
to generate an XML report as the result of preflight.

The XML file contains all of the information contained in the PDF reports
(and much, much more) and it is of course ideal to be parsed by
automated processes or scripts down the line.

Want to show preflight results embedded in a web site?
Write some PHP code to parse the preflight report and
you have everything you need.

Have an automated workflow using FileTrain or Switch?
Feed it the XML preflight report and you can base further file decisions
on the information in the report.

Multiple reports

Don’t think that you’re limited to just one type of report.

In all of the automated versions of pdfToolbox or pdfaPilot
you can preflight once and receive multiple types of reports as a result.

This makes it painless to setup a workflow where

• a PDF report is sent to a client and


• an XML report is used to feed in a database or other job tracking system.

One of the biggest strengths of pdfToolbox is its ability to preflight PDF documents
and return a detailed list of errors and warnings about a PDF file.
But in some cases “good” or “not good” simply isn’t a detailed enough answer.

In such cases pdfToolbox (and pdfaPilot)
provide the visualizer to visually inspect a PDF file.

Ink coverage

Perhaps the best example of cases where the visualizer proves its worth
is when a preflight check tells you that a PDF document uses too much ink.

Figure 1: Visualizer showing ink coverage for a PDF document

The ink coverage mode of the visualizer overlays the PDF document
with a gray mask and highlights any area of the file that goes over a
certain threshold with bright colors: yellow for small overruns,
progressing to red and purple for serious overruns.

This gives you an immediate view on how serious the ink coverage problem is
and can help you decide whether the file could still be printed or not.

Separations

In cases where you doubt whether a file will separate correctly, or you simply want to
examine the ink mix or overprint of certain elements the visualizer comes in handy as well.

It provides a number of different separation preview modes to view single separations,
just the process separations, just the spot color separations and more.

Figure 2: Visualizer showing the cyan separation only

When previewing separations, pdfToolbox here also shows the total ink amount
(in percentage of the surface of the trimbox and in square cm) for separations.

This information could of course be used in cost calculations.

Safety zone

While pdfToolbox and pdfaPilot provide a preflight check to
detect whether objects have enough bleed.

This again is an area where visual inspection can often decide
more accurately whether a document is in fact good for print or not.

The visualizer has a “safety zone” mode in which it highlights either
the page border or the bleed area.
These tools can help greatly to help judge a particular PDF document.

Figure 3: visualizer previewing the bleed area

Problems with incorrect color spaces and colors are a very frequent problem
in graphic arts workflows and pdfToolbox offers a lot of functionality in
this area to resolve such problems.

Preflight

First of all, of course pdfToolbox fully supports preflighting on color.

In a preflight profile it’s possible to check on the use of RGB, spot color,
calibrated color spaces (such as ICC-based color spaces),
output intent used and much more. This gives you a complete solution
to make sure the color you receive is actually what you want.

Color conversion with ICC profiles

pdfToolbox Desktop has a dedicated Switchboard action
for this type of color conversion.

Figure 1: Process conversion tab in the pdfToolbox Switchboard

This allows you to specify which type of file you are converting,
what colors you want to convert (in the example everything will be
converted with the exception of spot colors) and what your target is.
This is a manual or interactive conversion and of course you can also
perform this automatically with pdfToolbox Server/CLI/SDK.

Figure 2: Fixup to convert all colors to ISOCoatedv2

Such a preflight profile can be executed in all
pdfToolbox products (Desktop, Server, CLI and SDK).

Color conversion using DeviceLink profiles

When converting from CMYK to CMYK or for special processing,
such as TAC reduction or ink saving, color conversion based
on DeviceLink profiles gives better results.

See also this callas software blog: Why DeviceLink profiles should interest you.

• Manually applying DeviceLink profiles

In pdfToolbox Desktop, the color group on the Switchboard contains
the “DeviceLink conversion” item.
Here you can select a DeviceLink profile to use, determine on which
objects you want it to run and what color spaces you want to convert.

• Automatically applying DeviceLink profiles

Again using a fixup, the same technique is available in automated workflows.

The example fixup implements TAC reduction
for PDF files using a ColorLogic profile.

• Where to get DeviceLink profiles

pdfToolbox is only capable of applying DeviceLink profiles on PDF documents;
it does not contain a profile editor or creator.

To use the DeviceLink functionality, one will need DeviceLink profiles
and there are a number of options in this regard:


• Use the DeviceLink profiles included in the DeviceLink option for pdfToolbox,
  a separate, payable, option that will provide you with a list of important
  DeviceLink profiles, mainly targeted towards converting between
  standards (such as between SWOP and ISOCoated).


• Use your own DeviceLink profiles.
  There are various tools such as CoPrA from ColorLogic to create DeviceLink profiles.
  What is important is to make sure that these profiles are open or unsecured
  so that they are usable in pdfToolbox.


• Purchase a DeviceLink pack created by another vendor.
  Such a pack contains pre-made DeviceLink profiles created by that vendor.
  A good example of such a vendor is ColorLogic which sells a wide range of
  DeviceLink packs that include the possibility to convert between standards,
  do TAC reduction or can be used in ink saving scenarios.

Working with spot colors

Changing or removing spot colors is another common question and
pdfToolbox implements a wide range of functionality around spot color.

In pdfToolbox Desktop you can interactively work with
a list of spot colors in a PDF document.

For each spot color you have the possibility to change its name,
alternate color space and values, remap it to a process color or
other spot color or simply convert it to CMYK.

In an automated workflow you’re again better off using a fixup to
remap spot colors or convert them to CMYK.
The “Map spot and process colors” fixup makes it possible to
remap spot colors or convert them to CMYK.

Fixing common color problems

In practice there are also a number of common color problems
that don’t involve any of the previous color conversions.
An example is correcting four color black which is shown in the example fixup below.

pdfToolbox provides fixes for all common color problems, including:

• Converting four color black to real black


• Converting the color “All” (separation black) to real CMYK black


• Converting rich black to real black or vice versa


• Setting black or gray objects to overprint and white objects to knockout


• …

Which of these fixes are suitable for your workflow
is a decision you need to make.
But pdfToolbox does include all of this functionality to make it easy for you
to correct whatever you feel you need to correct in PDF documents!

Performing quality control and preparing documents for archival is a pretty
specific task for which the callas products pack a lot of punch.
Read the following solutions to understand how to harness that
power to make your archival workflow go smoother:

• 2a. Creating archive-ready PDF files


• 2b. Archiving emails and attachments

More and more, PDF/A (the ISO standard for long-term archival of PDF documents)
is becoming the file format of choice to archive documents.

pdfaPilot is an all-round expert in creating
archive-ready PDF/A documents;
read on to get lots of background on what is supported and how to go about this.

Different versions and flavors of the PDF/A Standard

The first questions when thinking about creating PDF/A documents
is usually which version and flavor of the standard should be used.

The full list is:

• PDF/A-1a, PDF/A-1b


• PDF/A-2a, PDF/A-2b, PDF/A-2u


• PDF/A-3a, PDF/A-3b, PDF/A-3u

Versions and Flavours

PDF/A-1 was the original version of the standard;
it doesn’t allow a whole list of modern PDF features such as
transparency, forms of compression for images and layers.

PDF/A-2 extended support for these features and also opened up
the possibility to store other PDF/A files inside a PDF/A-2 file
(allowing a PDF/A-2 to behave a little like a small archive if you want).

PDF/A-3 is the most recent addition and opens up the way to store
any file inside a PDF/A-3 file. This allows email attachments to be
stored in their native form inside the archive email for example,
or electronic invoices in PDF/A-3 format that have the invoice data
embedded in them as XML.




Flavors

The “b” or “basic” flavor is focused entirely on visual reproduction;
the only thing that counts is to be able to see the document on screen
or print it exactly as it was put in the archive.

The “a” or “advanced” flavor adds additional requirements.
Text must be embedded in such a way that it can easily be extracted
(the meaning must be clear, not just the visual appearance),
images must have alternative text associated with them
(again to make their meaning clear) and all elements in the PDF/A
must be tagged (to be able to distinguish between different heading levels,
body text, find paragraphs and tables etc.).

The “u” or “Unicode” flavor sits somewhere in between “b” and “a”.
It focuses mainly on visual reproduction, but does require that
all text can easily be extracted or searched.




Which PDF/A Standard should you use?

That very much depends which types of documents you are archiving
and what features you want to enable in your archive.

Keep in mind that it’s much easier to create a “b” PDF/A file than an “a” PDF/A file
(because of all of the additional requirements).

What is good news is that pdfaPilot supports all versions and all
flavors of the standard, so you have total freedom on that front.

Interactive verification or conversion of PDF/A

pdfaPilot Desktop provides different ways to verify compliance of a PDF with your
PDF/A version of choice and different ways to convert (or attempt) to convert a
PDF into your PDF/A version of choice.

The easiest way however is the “PDF/A in one click” window.

Figure 1: The PDF/A in one click window in pdfaPilot Desktop

Using the action button (the button with the gear icon in the top right corner)
you can select which PDF/A version and flavor you want to work with.

The window then offers two buttons,
once to simply check an opened PDF file against the PDF/A standard you selected,
the other to convert it to that standard.

Using the pdfaPilot preferences, you can select whether you want to enable
fallback methods if regular conversion to PDF/A fails.

Fallback methods for conversion

Fallback methods are used when pdfaPilot has attempted conversion to PDF/A
and that conversion failed.

As a fallback you can:

• Convert the complete document to PostScript and then back to PDF.

This forces a number of newer PDF features to be converted to older features
and it rewrites the PDF file from scratch, which sometimes fixes problems.



• Convert pages with problems to images.

If specific pages have problems, pdfaPilot will convert just those pages
to images and insert them into the PDF instead of the original page.



• Convert all pages into images.

If nothing else works pdfaPilot can create a completely new PDF document
and insert an image version of all pages of the original PDF into this
new PDF document in a last ditch effort to fix the problems that exist
in the original PDF document.

Of course these fallback methods take time and often imply degradation
in quality for the document that will be put into the archive.

It is up to you to decide whether you want to use these fallback methods.
If clients submit files to you and you absolutely have to put something in the archive,
there sometimes is no other choice than work with fallback conversion for
troublesome PDF documents.

Automating the process

In most cases the volume of files to be put in an archive is huge;
callas pdfaPilot Server can easily handle such volumes and process
PDF documents in an automatic, unattended way.

Figure 2: A pdfaPilot job to automatically convert to PDF/A-1b

pdfaPilot Server lets you create jobs, where each job has a watched folder,
an associated profile and a number of output folders defined.
All files that arrive in the watched folder are automatically picked up
and processed with the selected profile.
The result is dropped in the success or error folder
depending on the processing result.

Integrated preflight

Often the most efficient way to check PDF files for compliance with
your PDF/A standard or to convert them to it, is integrated in a larger
solution such as a web portal or document management system.

callas provides both a command-line solution and
a real SDK to support these scenarios.

• Command-line integration

  pdfaPilot CLI is a command-line application;
  it can be started from a terminal or command window,
  but is typically launched from the application or script it are integrated with.

  This version of the pdfPilot application supports all of the PDF/A capabilities and
  can automatically generate detailed reports (in PDF or XML) for further automation.

  
  

• Integration using the SDK (Software Development Kit)

pdfaPilot SDK is a solution providing integration on a library level.
The SDK contains the necessary libraries, headers, documentation and code samples
to integrate PDF/A support closely in a C, C++, Java or .Net application.

This requires development resources but allows for
the closest possible integration in the end.

In today’s world, emails are an integral part of regular business communication;
there are many laws and regulations that state they have to be archived
just as any other business documents.

pdfaPilot fully supports email archival both interactively and automatically.

Conversion mechanism

pdfaPilot does not integrate in incoming or outgoing email servers to do its job;
instead it converts email messages in msg or eml formats
(the two most widely spread email file formats) into PDF or PDF/A documents.

This conversion can be done interactively in pdfaPilot Desktop,
using watched folders in pdfaPilot Server or integrated into other solutions
using pdfaPilot CLI and SDK.

Supported conversions

Depending on the email itself and on what output file is needed,
pdfaPilot offers different conversion possibilities.
All possibilities can be seen in the Switchboard implementation below.

Figure 1: E-mail to PDF options in the Switchboard

Explanation of each conversion possibility and its implications:

• PDF: Embed attachments as original.

Generates a regular PDF document and embeds any attachments from
the email in the generated PDF document in their original format.



• PDF: Embed attachments as PDF.

Generates a regular PDF document.
If the email has attachments they are converted into PDF documents and
then embedded in the generated PDF document.



• PDF: Embed attachments as original and PDF.

Generates a regular PDF document.
If the email has attachments they are converted into PDF documents.
The result of the conversion to PDF and the original attachments are
both embedded in the generated PDF document.



• PDF: Add attachments as additional pages.

Generates a regular PDF document.
If the email has attachments they are converted to PDF and
appended at the end of the converted PDF document as additional pages.



• PDF/A-1: Add attachments as additional pages.

Generates a PDF/A-1 document.
If the email has attachments they are converted to PDF and
appended at the end of the converted PDF/A-1 document as additional pages.

This is the only option for PDF/A-1 because the PDF/A-1 standard
does not allow embedded files (whatever they are).



• PDF/A-2: Embed attachments as PDF/A.

Generates a PDF/A-2 document.
If the email has attachments they are converted into PDF/A-2 documents and
then embedded in the generated PDF/A-2 document.



• PDF/A-2: Add attachments as additional pages.

Generates a PDF/A-2 document.
If the email has attachments they are converted to PDF and
appended at the end of the converted PDF/A-2 document as additional pages.



• PDF/A-3: Embed attachments as original.

Generates a PDF/A-3 document and embeds any attachments from
the email in the generated PDF/A-3 document in their original format.



• PDF/A-3: Embed attachments as PDF/A if possible.

Generates a PDF/A-3 document.
If the email has attachments they are converted into PDF/A-3 documents and
then embedded in the generated PDF/A-3 document.

If conversion to PDF/A is not possible for a particular attachment
it is embedded in its original format instead.



• PDF/A-3: Embed attachments as original and PDF/A.

Generates a PDF/A-3 document.
If the email has attachments they are converted into PDF/A documents.
The result of the conversion to PDF/A and the original attachments are
both embedded in the generated PDF/A-3 document.

• 3a. 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 (such as 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 in pdfToolbox and pdfaPilot!

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 (above)
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" 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…