By Rich Huff
Madison Advisors

Variable-Data Applications
A successful variable-data application requires data. No matter which software solution is used to drive the application, all will require a standardized data file that follows a pre-defined format. Prior to building the application, the organization must determine what data is available, what format it is in, and which data points will drive the variability.

Using data collected through customer transactions, organizations are planning applications to promote products and services that the customer has not yet purchased. The applications are developed using a range of variable-data software packages ranging from simple desktop tools to robust server-based software. The capabilities of the software determine the complexity and variability of the application as well as how quickly they can generate the volumes. After creating an application and preparing for the merger of data and associated graphics and images, a printer needs to receive the output in a form that it can handle. Publishing page description languages (PDLs), like PostScript, are not always well suited for variable-data applications.

Languages based on PostScript, such as Creo’s (www.creo,com) Variable Print Specification (VPS) and Xerox (www.xerox.com) Variable-data Intelligent PostScript Printware (VIPP), are designed to handle complex variable- data applications. These languages process static components once and cache the components for re-use throughout the print run, so they require the processing of only the unique elements on each page, such as the variable data itself.

The printers require digit front ends (DFE), also known as raster image processors (RIP), to assemble the complete picture of the what output is going to look like, separate the images into the appropriate colors, and send the information to the printer. Understanding the capabilities and limitations of the various digital front ends is as important as understanding the capabilities of the variable-data software, so that the designers don’t create applications that cannot be produced.

Digital Front End
The role of the digital front end is to allow organizations to make the best use of their expensive printing systems. Simple desktop printers don’t need management and control systems, because the output is inexpensive. They simply print whatever is sent to them. Color laser printers, production printers, and digital presses are more expensive to operate and have a high cost-per- page. The digital front end serves as a control point to give the organization control over the print device.

The first point of control is provided through the printer driver. By making the printer driver available to individual desktops, the users within the organization learn what capabilities of the print device are available for their use. Users can select duplex printing or collation using the printer driver for documents that need these features, allowing them to minimize the use of paper or manual finishing.

With the demand for more sophisticated documents, the capabilities of the digital front end grew to accommodate the complexity of the page layout and leave the production to the printer, shielding it from the page manipulation. To a printer, an eight-page paper and an eight-page booklet are almost the same. The DFE is responsible for positioning the pages in the booklet on the right sheets of paper and adding the cover the user requests from a previous job. The DFE is responsible for pulling together the necessary images and building data-driven graphics on the fly so that the printer receives a fully composed document. When the printer tries to handle all of these functions alone, it cannot print anywhere close to the maximum rated speed.

Page Description Languages
The key to matching the right digital front end with a variable-data software solution is finding a common page description language (PDL). While all of the DFEs listed below accept PostScript as an input, it is not the most efficient PDL for variable-data applications. A number of PDLs have been created specifically to handle variable-data applications by sorting out the static elements that are reused on each page from the variable images and dynamic graphics that are constantly changing.

Xerox’s Variable-data Intelligent PostScript Printware (VIPP) organizes all the images, forms, and other page elements into a package, which is stored at the DFE the first time a job is run. For each successive run of the application, only the new data or data and template need to be sent to the DFE. VIPP takes the new data and builds the new documents, re-flowing text, and incorporating new data-driven graphics as needed. VIPP is PostScript with additional commands for handling variable data. Designers can use software from Xerox partners to develop variable-data applications or edit the VIPP code directly for complex applications.

Creo’s Variable Print Specification (VPS), also based on PostScript, separates each page into elements and identifies which elements are unique to each page and which elements are repeated. Each element is only sent to the DFE once, where it is processed and stored for reuse. Once a document is processed, the user can preview it and impose it prior to printing.

Introduced in May 2000, the Personalized Print Markup Language (PPML) specification is an XML-based model for describing variable-data documents at the object level. This allows the entire document to be broken down into reusable objects, which can be stored briefly or archived at the DFE and recalled when needed.

All three PDLs offer productivity improvements over PostScript for variable-data applications and differ from each other in the handling of variable-data sets and reusable images. Depending on the printing environment, different applications will be better suited for different PDLs. It is likely that in addition to PostScript, a production print shop may need to support several other PDLs.

Digital Front Ends
When comparing different DFEs, the volume of pages is also important. Applications generating thousands of pages will need to be produced on high-speed print devices or clusters of mid-range printers. Clustering is a technique that divides a large print run across multiple printers simultaneously to achieve very high print speeds. T/R Systems’ MicroPress supports up to 12 printers, including monochrome and color printers. The OneRIP from AHT also allows printer clusters of up to ten monochrome and two color printers. These systems can perform load balancing across the different print devices, tracking which printers are idle and routing work to those printers or send copies of the same job to multiple printers, if the job calls for more than one copy. This allows the job to finish faster, but requires the operator to gather all the copies from different printers.

The variety of print devices is a limiting factor for selecting a DFE. In many cases, the chosen printer or digital press will only work with one or two front ends. It is often the case that a single DFE will drive only one dedicated print device, requiring a new DFE for each copier, printer, or imagesetter.

Administration
Where there is an option to select between two or more digital front ends from different vendors, the software interface is a differentiator. Each vendor has developed an interface for submitting, managing, and processing jobs, which is common across its family of DFEs. This allows production shops with more than one print device to select DFEs from the same vendor with the same interface, thus reducing operator training and confusion.

In production environments, the operator controls the print production through the graphical interface of the DFE. Basic controls allow the operator to select which jobs to process and which attributes, such as trapping and imposition, are to be applied. The operator can also start and stop the printing process and save jobs for future printing.

In an office environment with a high-speed color copier or digital printer, the users might also be allowed to control the processing and printing of their own jobs. In this case, additional security may be required. EFI’s Command Workstation, the administration software for the EFI Fiery DFEs, offers three levels of access–administrative, operator, and guest, which allows administrators to configure the hardware settings and access levels, allows operators to download files and manage print jobs, and allows users to view print queues and submit print jobs.

Larger organizations may also require remote administration. Accessing the DFE across an Intranet through a Web interface, administrators can monitor activity and identify problems. Using the Xerox DocuSP, the user can view the production and accounting information across an Internet or intranet connection.

Production facilities often need to drive significant volume through the printers to stay competitive. To do this, the DFE must be able to multi-task and send one job to the printer while processing another. Due to the size and complexity of variable-data jobs, it is also useful if the DFE can start sending the first part of the variable-data job while still processing the remainder. Otherwise the operator needs to wait until the entire job is processed or needs to break up the job into several smaller jobs to get the printing started sooner. Creo refers to the concurrent processing and printing of long documents as gallop mode. This feature reduces the time it takes the Creo Spire to complete the job and reduces the amount of disk space required, since the entire job does not need to be stored on disk prior to printing.

Another valuable feature, in both production and corporate environments, is the ability to preview a job. This is particularly valuable for large or complex documents that may take a long time to print. A viewer allows the operator to see the processed document prior to sending to the printer. If page elements are missing or the wrong settings have been used, the operator can make adjustments or send the job back to the user without tying up the printer or wasting consumables.

Workflow
The steps the document must go through prior to printing are called the workflow. A simple printing workflow would be to receive a job from a desktop computer, process, and then print the document. Production printing and variable-data jobs require more manipulation and handling. The digital front end can handle many of the automated processes.

The workflow starts with the job submission. Ideally any user on the network can submit a job to be printed. The printer driver displays the processing options available and the user selects the ones to be applied to the document. The Xitron Xenith can accept jobs from both Macintosh and PC-based clients, while the AHT OneRIP also accepts jobs from Unix and AS/400 clients.

Production printers and reprographics shops can allow some customers to submit indirectly through Web site. Since the user may not have access to the printer driver, a job ticket is associated with the file to identify the job parameters including layout, number of copies, finishing options, and file manipulation. Although each DFE uses its own job ticket format, some can accept other job ticket standards as well. Created by the CIP-4 vendor consortium, the Job Definition Format (JDF) is an emerging, non-proprietary job ticket format. Written in XML, a JDF contains the prepress and print instructions for a single print job.

In many cases, either the user or the operator can assign the priority to the job. This may determine the scheduling of the job or the printer selection, if a printer has been set aside for high priority jobs. While most DFEs support priority settings, few allow the exact print time to be scheduled.

Once the job has been submitted, the preflight process looks for critical errors that might cause the job to fail. If incorporated as an automated process, preflight software will look for fonts or images used in the document that are not available to the DFE and were not provided by the user. This prevents the document from being printed with the wrong font or missing images. This is very important for variable-data jobs, which may contain hundreds of images, but may only use an image once under specific conditions. If problems are found, the operator can notify the user or access the job to locate missing items.

Trapping is a technique for adjusting the borders of characters or objects of one color when they overlap objects of another color. Since the physical printing process puts down one color at a time, misregistration may occur, causing a white gap to appear at the border of the two objects. Trapping provides a slight overlap to accommodate for any color that is slightly out of alignment. By performing this process at the DFE instead of the desktop, the system can account for color-on-color instances generated by variable data, which may not appear until the entire document is assembled.

Image replacement is a process for replacing the low-resolution images used by the designer with high-resolution equivalents. The low-resolution images are used for placement within the document, but would appear rough and grainy if printed on a digital printer or press. Most desktop publishing applications place tags in the PDL to tell the DFE where to go on the network to find the high-resolution image. Typically once the DFE has located and processed the image, it is stored on disk for reuse.

Depending on the audience and purpose of the printed document, color can be an important element of the message. The print device needs to produce consistent and accurate color. Since the printing is a mechanical/chemical process, the colors a device produces can change over time and may not match the colors produced on a second device. Color profiling software measures the color produced by each device (monitor, scanner, and printer) and creates a list of adjustments for each device to make the colors match. In a production environment, the user may not know which printer the job gets sent to, so the DFE needs to maintain the color profile for each color printer it sends files to and adjust the colors in the document accordingly. The CADLink Technology’s PhotoScript is capable of managing output for four and six color printers with the appropriate color management and color profiles.

Although every job may not need to go through every workflow process, organizations need to make sure that the DFE is capable of supporting all the workflow processes that their printing environments will need. Organizations developing variable-data applications also need to consider the capabilities of the DFE in order to understand which processes need to be performed up front in the design stage before sending the job to production.

Conclusion
Just as software solutions are geared towards certain types of applications, the various digital front end systems are also suited for certain types of applications. Systems designed to drive image setters and wide-format printers are best suited for specialty applications in service bureaus and manufacturing environments.

Systems designed to distribute and print documents must process the entire document, before routing to one or more print devices. These systems require good tracking and error handling to ensure that the entire job has been printed correctly and can be assembled easily.

Page-oriented systems process jobs at a page level and are capable of sending the first part of a job to the printer while processing the remainder, but are tightly linked to a single printer. While capable of accepting jobs from across the network, the system is usually placed right next to the printer and job assembly is less of a concern. Because of their ability to print while processing, these systems are best suited for variable-data applications where the various page elements are processed once, but used repeatedly in different combinations for each page or document.

Mar2003, Digital Publishing Solutions