American Printer's mission is to be the most reliable and authoritative source of information on integrating tomorrow's technology with today's management.


Aug 1, 1999 12:00 AM

         Subscribe in NewsGator Online   Subscribe in Bloglines

Preflight has been around for a long time in one form or another. Checking mechanicals always was a customer service function, but as we moved to digital page production, somehow those customer service representatives (CSRs) got left out.

So what is preflight anyway? It is a way to inspect and qualify materials received from customers to ensure that they are compliant with the rest of the process. This keeps the confusion to a minimum when the electronic file moves on to production, resulting in a smoother workflow. In the pre-digital days, preflight consisted of opening an envelope, lifting the cover sheet on a mechanical and reviewing it for content, missing pieces, size, color, etc. Today, it really isn't that different --it's just that the tools required now need to support an electronic "mechanical."

The real differences between then and now is that there used to be distinct breaks between design and prepress, and prepress and platemaking. They were built-in opportunities to catch errors that may have crept into the job. In the brave new world of completely digital workflows that flow from design to print to finishing, there are no "stops" along the way to conveniently catch mistakes.

As a result, preflight is added to the beginning of the process. But who is responsible for this step in the process? Is it customer service, production or, perhaps, a hybrid position whose skills encompass production and customer service?

In many cases, this determination is based on the amount of available time or equipment resources in the customer service area to complete the task. Preflight isn't rocket science, however, and more importantly, current software tools allow this function to be effectively done by staff members with average skill levels. The key to preflight is ensuring that work doesn't enter into the production process if it doesn't meet certain pre-established criteria. In order to adequately perform the preflight function, two questions need to be answered:

1. Do you know what the customer wants?

2. Do you have all of the appropriate pieces to go into production and produce what the customer expects?

Minimally, a CSR should view the file and feel comfortable about what he or she sees. While this might seem rather obvious, many CSRs don't look at incoming files prior to sending them into production.

Answering the second question posed above requires an understanding of the process requirements of specific systems. These can vary greatly from one printer or prepress house to another. They usually are determined by the type of workflow your plant has and, in many cases, the equipment that has been purchased.

If you can answer the two questions, however, you have completed the preflight process. Preflight can be done manually, by opening each page file, checking the file and each of the components for process conformity. Also available are more automated preflight checking applications.

The need for preflight is directly related to the industry's expertise in custom manufacturing. Any manufacturing process is made up of discrete tasks. Each task has a set of guidelines that must be met, but, more importantly, each one also has requirements that need to be met prior to performing subsequent tasks.

For example, if you are making ice, you need to fill an ice cube tray with water, put it in the freezer and set the temperature of the freezer to the correct level. If you don't fill the tray with water, however, or fill it with beer instead, it will affect the end result in terms of process time, quality of the end product or both.

In the publishing process, there are many tasks that need to be done in order to accurately complete the required project. The end result of some of these tasks is a file component. These components include text (along with required fonts), raster images and vector images. Each one of these components has specific requirements that it needs to meet. Preflight is the process of ensuring that each of these components is compatible with the process.

There are multiple levels of preflighting that could be performed, and there are a variety of places in the process. The adjacent diagram shows an overview of the page production process and the places where preflighting can occur. It also illustrates the types of compliance that can be checked at each step.

Depending upon your firm's individual systems and processes, you may have the ability to do preflight at different points. The key issue is to understand that the later the preflight is performed, the more time and money has already been spent and the less editable the files are.

The distinction between preflight and fixing files is sometimes confusing. As in the checking of conventional mechanicals, there are two separate and distinct operations. Preflight checks incoming work to a set of process specifications. Fixing those areas that are non-compliant is not part of preflight, but falls into the production arena.

Customer service should leave the "fixing" to the production personnel in order to ensure accuracy, accountability and proper billing. It is important to allow CSRs to do initial preflight to ensure that production operators aren't burdened with files that are completely non-compliant. This can disrupt production schedules and force operators to accumulate non-billable time.

So what exactly should CSRs be checking?

hard copy. The preflight process can attempt to check different components, but ultimately the most important check is that of content. In the "old days," that meant looking at the mechanical and checking it against a known or understood visual. In the world of electronic page production, the needs are the same.

While you would expect that a file created on one computer could be opened and viewed on another computer (and still look the same), this isn't always the case. At a very basic level, the CSR could have the wrong file or version of the job.

Beyond that, the settings of some of the system utilities could affect the look of the file. The application settings also could affect viewing and ultimate output. While there has been an attempt to address some of these concerns through a variety of upgrades over the years, this still remains a problem. So the most important thing to do is view the file against some form of hard copy (printed sample). The only thing that can't change when you send it from one place to another is something on paper.

The next most reliable method of content proofing is a PDF file. The key is that the PDF file needs to have been created properly, with all of the fonts included. It also needs to have been subsequently checked to ensure it is correct prior to submission. A properly made PDF file can provide the same function as hard copy.

size. Even if a preflight application provides size information automatically, this doesn't necessarily mean that the document is the correct size. Part of the problem is that the preflight applications can only detect the file's established page size. It does not know if the file includes bleeds or extraneous information.

The only way to realistically determine size is to measure the file. Fortunately, this is easily accomplished with most graphics creation or page layout programs, including Adobe Acrobat. They all include rulers or measuring tools.

color. Before electronic publishing, the main issues that affected color concerns on incoming mechanicals were process or spot. Increasingly files are used and reused for a number of different applications, each requiring a variety of output forms. Now that we are moving into cross media production and distribution, we need to be concerned with checking if the files are RGB or CMYK.

CMYK files are needed for print unless output systems are configured to handle conversions. The ability to do RGB or CMYK conversions on the fly is just starting to become more available. Printers and trade shops need to ensure that they have this capability before defining preflight requirements.

text/fonts. Checking text is akin to proofreading, and not always part of the CSR job responsibility or production operator. In some cases, however, it is part of the preflight requirement. In any case, fonts always are necessary, and an important part of the supplied files. Make sure that the fonts used to create the original page files are the same ones used to process those pages.

In addition to font and font family differences, there are two types of font files that can be used in the page production process--Type 1 and TrueType. Type 1 fonts were originally developed to conform to the requirements of a PostScript workflow. TrueType fonts were created later and are natively supported by Windows and the Apple OS.

Until recently, using TrueType fonts in a PostScript was like playing Russian roulette--sometimes it worked and sometimes it did not. With advancements in Adobe Type Manager and RIP technology, this problem has been minimized. Functionality is still dependent on a number of specific software tool versions, however, so use of TrueType fonts in a PostScript workflow must be checked.

raster images. Image captures from scanners, digital cameras or files created with paint programs such as Photoshop are composed of pixels (also known as rasters). These raster files are usually defined by the pixel values (color) and the amount of pixels distributed in a given space (resolution). While the color specification issues are the same as those mentioned before--RGB, CMYK or spot--resolution issues are more complex.

First understand that resolution is what determines detail. While there are other factors that can determine detail in a raster file, usually the higher the resolution, or the more pixels in a defined area (inch, mm, etc.), the more detail exists. The amount of resolution required in a raster image for output production is defined by two factors: the output resolution (the amount of pixels the output device can image) and the line screen.

Determining a correct amount is mathematical--comparing the input resolution to the output resolution, or linescreen, depending on whether it is line art or halftones. This then needs to be multiplied by any scaling that may occur in the layout. While you could calculate this yourself, most of the preflight packages do this, allowing users to set the acceptable ranges.

vector images. These are images created with lines and shapes in programs such as Adobe Illustrator, Macromedia Freehand, Corel Draw, etc. Unlike raster images, vector images don't use pixels to define their file content. That being the case, there are only two defining issues that need to be checked: color and whether or not any fonts were used in the creation of the images. Fonts used in the creation and not necessary for output can be any text that might have been converted into "paths" (vector lines and shapes).

other process or system specific issues. As we discussed, preflighting is about determining a file's conformance to a process. Process requirements can be affected by hardware, RIPs or other software. Each of these differences adds various requirements that need to be met to achieve successful output.

Things like high-res/low-res image swapping (OPI, APR, etc.) add additional checks to the process. In addition, pre-separated workflows (separations being performed by the layout application) vs. composite workflows (separations performed by the RIP) add other issues to the mix. Additionally, file type, picture box transparency, the use of clipping paths, etc., may need to be checked. Each of these issues must be identified and understood prior to defining the process requirements that need checking.

All of which leads us to where in the process preflighting should be done. application. As seen in the diagram on pages 26-27, the first, and perhaps best, place to check files is at the layout application stage. At this point, most of the areas of non-compliance can be identified. At this stage, the two most widely used preflight applications are Markzware FlightCheck and Extensis Preflight Pro. These applications can be set to check the necessary requirements for successful output. They are also both configurable, to allow users to customize the software to specific process needs.

postscript. The next place files can be checked is in the PostScript file. PostScript is a consolidated file format that retains the full data integrity but not the creating application specificity. For example, the vector images created in Illustrator or Freehand are still vectors, but once in PostScript, can't be opened in their original creating applications.

Raster files scanned or created in Photoshop are still raster files, but can't easily be isolated from the PostScript file to open back up in Photoshop. Resolution, size and other information do exist, however, and can be determined.

PostScript file checking can be accomplished with applications such as Flight Simulator from Ultimate Technographics, Download Mechanic from Acquired Knowledge or Transverter Pro from Techpool. In addition, PostScript preflighting is an included utility in many of the output RIP manufacturers' systems. In each of these cases they can check for inclusion of fonts, proper color space and image inclusion, and check image resolutions.

Each of these utilities actually RIP the PostScript file and check it as part of the process. Alternately, you can preflight PostScript files without RIPing, using utilities such as Markzware's FlightCheck. The advantage to checking PostScript with a utility that RIPs is that you can also determine if there were errors created at the time of the PostScript creation. While this isn't as big a problem as it once was, it does happen occasionally.

pdf. Preflighting PDF files is similar to PostScript but it is also different. Just like PostScript, PDF files are consolidated file formats that retain full data integrity without the creating application specificity. But PDF files are higher on the evolutionary scale than PostScript. They offer, among other things, page independence and a simpler file structure, and can be opened, viewed and even edited. If nothing else, this allows users to check content.

There are still other things that need to be preflighted in a PDF file, however. Many tools are available to provide those resources. These tools can be broken into two categories: plug-ins that work within Acrobat and standalone applications.

In the category of plug-ins there are EnFocus CheckUp, EnFocus PitStop (which also has editing capabilities), PDF Toolbox from Callas and a number of others that are soon to be released. Information on many of these can be found at, a PDF information clearinghouse.

In the category of standalone applications, there are Extensis PreflightPro, Markzware FlightCheck, and the applications previously listed from Ultimate and Techpool. ripped files. For checking RIP ed (or rasterized) files, the choice of preflight application is dependent on the rasterized file format. If you are checking TIFF/ IT files, AdCheck from Total Integration would be a suitable tool. It allows users to view the LW and CT files together and checks color, resolution and size--the main checkable attributes of this type of file.

If you need to check Scitex LW/CT files, you can use SciNet Span Pro, a Scitex utility for checking the same basic attributes as those checked with AdCheck.

screened bitmaps. A screened bitmap file has been rasterized and the screening has already been done. It is similar to screened film, in that there isn't much you can do to it or check, other than screen angles and ruling, registration and size. You could look at content with appropriate viewing tools.

As we look toward the continued automation of the print publishing and production process, people are less involved in the process. The requirement for preflight, or process conformance, will still be necessary, but more automated. A whole new breed of applications soon to be released will automate the preflight process and offer provisions for fixing non-compliant files.

Applications such as Markzware iScout and Enfocus DoubleCheck fall into these categories. This software allows users to define a specific set of preflight requirements and correction guidelines. As these and other applications continue to evolve, preflight may become a transparent part of the process. For now, however, it requires a hands-on approach that ensures process compliance as early on as possible to minimize production time and expense.

For more information, please see the flowchart on page 32-33 in the August 1999 issue of American Printer.