Blog

In order to try to make a guess about the future, one must know and understand the past. Preflight has already undergone a transformation. I want to briefly describe what were the milestones of Preflight and draw some conclusions based on these:

Preflight – How it all began

According to Wikipedia, the term " Preflight " was first used for the printing industry in 1990. At that time, prepress staff checked incoming files manually. PDF was not yet invented, .ps and .eps files were delivered. Furthermore, there were no editors or even software for automated quality control for these file formats. For some common applications, such as QuarkXPress, there were native preflights.

In the mid-90s, the triumph of the PDF format as the standard for print files began and the first solutions for software-supported troubleshooting were introduced. One of the first software solutions had the beautiful name "1Vision".

Preflight in the 2000s

The popularity and general accessibility of the PDF file format allowed many people without profound design training to create PDF files and send them to printers. The quality of the files to be printed decreased accordingly. In addition, new PDF versions provided more and more options. Manual error checking was no longer fast enough and the first preflight software solutions were introduced.

The concepts and the basic ideas were the same for all of them: to find out automatically BEFORE printing whether a file was printable at all - the implementation, however, was already very different. Most providers relied on the PDF Library provided by Adobe and tried to analyse files based on it. In most cases, this resulted in the so-called "header" of the PDF being read.

OneVision did not want to rely on this header and even less on the PDF Library. We wanted to investigate the problems in more detail. For this we disassembled PDF files (just like EPS or PS files) into their individual parts and examined the elements, the file structure with our own library. This allowed us to make much more accurate statements about file quality.

A further challenge - independent of the analysis technology - is to communicate the preflight results to the user as accurately as possible, but at the same time, in an easily understandable way. There are completely different approaches, from simple text logs to PDF reports, in which the errors are visualized.

The trend during this time period was to move away from manual checking towards a professional tool for comprehensive troubleshooting and correction.

Preflight in the 2010s

In the 2010s Preflight was seen less and less as a pure "point of entry inspection". Initially, the " real production workflow " began only after a file had successfully passed the Preflight. However, Preflight was increasingly perceived as part of the workflow. Software was now available that prepared input files specifically for preflighting. With the help of software settings, each printer or prepress manager could define which file criteria should be classified as errors or which file properties should be corrected automatically.

If I know that fonts have to be embedded, then I can use software to automatically integrate missing fonts before preflighting.

If I know that no transparent elements should be passed to the RIP, I can flatten them before preflighting them.

If I know that my RIP does not process pages with more than 1,000,000 elements, then I can simplify such pages in advance and ideally optimize them for faster RIP processing.

etc.

So a race began: On the one hand, customers were incorporating more and more errors into files that prevented them from being printed, and on the other, software was developed to automatically correct these errors. And as always, there were different types of software solutions. Some were very cheap, with very limited functionality; others required a higher investment, but offered much more automation. Some stagnated in their possibilities, others continued to develop.

In these workflows, Preflight was no longer the check at the point of entry, but the last instance to find out whether all production-relevant requirements had been met. This in turn meant that the next automated steps could already be defined in the workflow, e.g. if there was an error found in preflight, then automatically inform the prepress department.

The trend in the 2010s was to no longer accept customer data as unchangeable, but to consciously and deliberately manipulate them in such a way that they appear correct in print. Preflight has changed from a pre-test to an end-test prior to print.

Preflight today

Preflight has been refined more and more over the years, the Asura Preflight for example checks over 130 different file properties. This knowledge about the nature of a file is not only used to keep files - like a gatekeeper - away from production. Today, preflight results are also associated with metadata in two ways:

Metadata: What is it and what makes it important?

Metadata is the properties that describe a file. They can either be provided in a separate file (xml Jobticket) or they can be included in the production file itself (file properties). In addition, a preflight can also be used to find properties that are not immediately obvious.

If we only used the pure PDF file for production, then each file must be processed in absolutely the same way, because there are no references to special requirements or properties of files. However, if metadata is taken into account, a much larger dataset is available to ensure targeted processing. Metadata as Input for the Preflight Here is an example that illustrates very nicely the importance of metadata: assuming I want to check if files have the correct page format. This value depends on the print product, which means that each print product requires an extra preflight or even an extra production line. Preflight must not only know the production file, but also the order data. These can be available as XML data, for example. Preflight can therefore use the page format value of the order data to check whether the actual production file corresponds to the order data. As a result, Preflight can either correct the page format automatically or return the file with a description of the error.

Metadata as Output of the Preflight

Preflight not only reads the header information of a file, but also examines it thoroughly. Preflight finds more than 130 file properties! All these analysis results are available in the further workflow as additional metadata. Some advantages:

If Preflight detects transparencies, files are forwarded for flattening. Without using the preflight results, all files would have to be flattened to be on the safe side, which creates unnecessary workflow load.

Preflight can check whether the file is composed purely of grey tones or contains CMYK parts and, depending on this, send the file to different printing presses..

Which destination is Preflight heading to?

Preflight has changed from a manual visual check to separate files from production to a dynamic final check for the production of prepared data. Preflight is metadata-compatible and thus the basis for intelligent workflow control.

I am convinced that the next evolutionary step is that Preflight will no longer need to be configured, Preflight will become intelligent:

Preflight will know which print product should be created with a file and will then make all workflow decisions independently.

Preflight will analyse files and use the results of this analysis to trigger necessary file manipulations.

Preflight will become the new brain of any PDF print production workflow