How callas and Prepress changed each other

Callas prepress

Anyone (like me) who has been on the road in prepress for some time might still remember the days before PDF when customers sent "open files" to printing companies. Then came PDF and the problems with missing resources (pictures or fonts) or unwanted changes to the layout could finally be solved. But it soon turned out that not every PDF file was printable. This led to the idea of a sub-standard based on PDF defining print related requirements on PDF, which was then published as PDF/X by ISO in 2001.

Preflight and Correction

This in turn led to the need for test tools to determine standard conformity. 'Preflight tools', such as our pdfInspektor, addressed this need around the turn of the millennium. Adobe also recognized this and integrated the pdfInspektor 2003 in version 6 of Acrobat Professional - even today, the preflight module in Acrobat is still based on callas technology.

But as great as these testing possibilities were, it was ultimately unfavourable to go back to the original file to solve problems. More and more correction possibilities for PDF were developed and in 2005, we therefore introduced the Acrobat plug-ins pdfCorrect and pdfColorConvert, with which about 100 different PDF 'internals' could be corrected.


2005 was also the year in which automation had gained more and more momentum. With Gradual Switch, a vendor-neutral workflow with a graphical editor was available. pdfInspektor, pdfColorConvert and pdfCorrect were therefore also available as command line tools, which could directly be integrated into Switch. In 2008, pdfInspektor, pdfColorConvert and pdfpdfCorrect were then combined into one product: pdfToolbox.


Already in pdfCorrect, it was possible to keep processing specifications variable and to overwrite them when called, and this variable technology was then also available in pdfToolbox. Variables are essential for the degree of automation in prepress processes achievable today. The background is the large number of Profiles for different print products. For example, a PDF/X profile uses approx. 170 Checks and approx. 25 Fixups. In addition, there are other product-dependent characteristics. Maintaining all of these would require a great deal of effort. We enable users to maintain a smaller number of Profiles using variables to check the PDFs according to different criteria.

Since version 9 of pdfToolbox, variables are "intelligent" and can be used for calculations. For example, values for one variable can be derived from another. Variables can also be used to increase integration options by transferring their values from integrating systems. More than 70 software providers now use our products as OEM variants.

Make Ready

Today, automated PDF processing is no longer about checking and correcting. Current challenges can rather be summarized as the need to 'Make Ready'. This started with the increasing number of online printing companies and web-to-print. This technology boost is reflected in numerous 'Engines' that are available in the core PDF engine of pdfToolbox.

One such engine is the shapes feature, which allows for deriving new content required for production from existing content, such as white or varnish forms or die cutting contours. Since pdfToolbox 9 the "Shapes" technology recognizes any filtered page content (vector, text or image) and then converts it into an internal shape. These can be easily enlarged or reduced and then used for an additional colour, as a mask or in another way.

Some Make Ready engines in pdfToolbox:

  • Imposition (callas' own engine)
  • Rendering and transparency flattening (Adobe)
  • Barcodes Engine (Tec-IT)
  • Add page content (pdfChip engine using HTML templates)
  • Intelligent Variables, JavaScript Engine (Google V8)...
  • Shapes (Tracing Engine)

Minimization of 'false error'

One of the biggest and still current a challenge for automation is ‘false positives’: Usually you would prefer to see too many “problem files” over missing problems. However, with the increasing PDF throughput via automation this gets less and less tolerable. The context-sensitive check technology, Sifter, introduced with pdfToolbox 10 addresses this issue. Examples of the use of this technology are the detection of whether an overprinting problem is relevant because an object overlaps another or not.

Integration of new PDF standards

In order to use PDF files even more efficiently for production control, you need more standardized information and we rely on new standards for that. An example here is the ISO standard Processing Steps which standardizes metadata for objects on layers to identify those belonging to production steps after printing. Processing Steps was published as ISO 19593 in 2019 and is mostly used in packaging and label printing. It identifies objects mostly for finishing processes, such as cutting, embossing and coating.

Another standard, Print Product Metadata, has just been published as ISO 21812. This is again standardized metadata, in this case, on pages in a PDF. Its technical foundation, DPart metadata was originally developed for variable data printing and transactional printing and is integrated into PDF 2.0. With Print Product Metadata, it is possible to attach information similar to a job ticket, e.g. information on tray control or color scheme, to individual pages In a PDF file. This makes it possible to control production not just on a document level.

Processing Steps is already comprehensively supported in pdfToolbox and our users will not have to wait long for Print Product Metadata. We assume that future PDF-based ISO standards will also be important building blocks in the design of cross-company processes where we will integrate them into our product portfolio wherever possible.

Back to overview

Subscribe to our blog newsletter for access to regular updates

No strings attached. Unsubscribe anytime. For further details, review our Privacy Policy.