Transforming and Automating Workflows: Production Infrastructures – The evolution of the DFE

David continues the discussion, now focusing on the production infrastructure by looking at the role of the DFE (Digital Front End, aka RIP), and how that has changed as a result of digital press technology and the changing demands of the marketplace. In keeping with the series theme, he looks at it with an eye toward building a flexible platform upon which to grow.

In the last few articles, we looked at some of the basic technology and representative products you could use that could comprise the business and information management layer of the PRIMIR Transformative Workflow diagram we are using as the basic model for our workflow transformation discussion. As described at the start of this series, we are covering the basics with some detail, without getting too far into the weeds, since that’s usually where your individual company requirements and the individual product features need to be closely matched. But the information in these articles provides a good starting point. There are many other products that could be considered in the business and information management layer. We expect to cover many more of them, along with the necessary workarounds, once we finish covering the basics and move on to the more tailored workflow solutions and implementations in future articles.

Now it’s time to start looking at the production workflows, their roles, requirements, and last but not least, how they will work together with the other workflow layers that have been identified in the PRIMIR model. We are going to start this discussion with the heart of any digital output system, the DFE.

The core piece of any digital production workflow is the DFE (Digital Front End). DFE’s have been around long before digital presses, but we used to call them RIPs. Technically, the RIP kernel is at the heart of the RIP controller. The RIP controller drives filmsetters, platesetters, proofers, etc. The role of a RIP controller or the DFE is twofold: First to present an incoming communication link to receive a file, and then to interpret the incoming PDF file (or historically, PostScript, or raster image file) into a bitmap file at the proper resolution that can be used to image on film, plate, paper, or other media. The other core function is to communicate that processed information to, and directly control, the output device as shown below.

At the heart of every DFE is an interpreter. In the past, this has been a RIP (Raster Image Processor) kernel which interpreted the file and then wrote the bitmap for imaging. In recent times we are seeing PDF libraries that perform a similar function, which is interpreting/processing the incoming PDF file into a bitmap. While early in the life of digital prepress there were many interpreter core developers , for many years now there have been two primary manufacturers of the RIP kernel or PDF libraries; Adobe with its PDF Print Engine (APPE) and Global Graphics (Harlequin and JAWS). This interpreter kernel is ‘the’ critical piece of the RIP/DFE since it actually does the translation from PostScript or PDF code into the bitmaps that print.

These kernels get updated on a regular basis to keep up with standards developments and other changes in market requirements. In fact, many of the problems that print service providers still have in correctly processing client files can be traced to either older interpreters or incorrect RIP/DFE settings. Additionally, not all RIP/DFE vendors develop around the same interpreter core the same way, which can also lead to differences in output. The various RIP and DFE vendors such as Agfa, Canon, EFI, Heidelberg, HP, Kodak, Océ, Ricoh, Xerox, and the others build their software around this core technology. Some of them add additional ‘value added’ features to replace or supplement the core kernel technology. This has the potential to create different output from different vendor software, even those using same version of the kernel. Both Adobe and Global Graphics usually stress to their OEM partners that this might present difficulties, and in fact, have they increased the feature sets in their RIP kernels to influence their OEMs to not behave in that manner. So you should be aware of DFE software updates and ensure that you are up to date and using the correct/optimal settings, which are not always what ships or installs, by the way…

The GWG (Ghent Workgroup) has been studying these problems for more than 10 years and has developed setting files in conjunction with many of the creation application and output device (RIP/DFE) vendors. Additionally, GWG has created a suite of test files that can be used to check your workflow and settings to ensure good file creation and output. GWG strongly recommends that you keep your creation software and RIP/DFE software up to date, since these updates help keep up with the many new changes and features in your clients’ creative software and also include bug fixes. It has been proven that the cost of keeping your software up to date is much less expensive than the costs associated with jobs going bad and the troubleshooting and workarounds that operators are forced to undertake to overcome this.

In addition to the interpreter core vendors adding features, over the years RIP/DFE vendors started to expand features beyond the core functions. New features added include various levels of JDF/JMF support, broader support of file types, variable data support, color management, trapping, imposition, and a number of other things that we will look at in future articles. Many of these functions were added to allow the output device vendor to offer a more complete solution when selling platesetters, digital presses, proofers, etc. The problem with these ‘fully featured DFE’s’ arises when print service providers try to automate and optimize their entire production system to support new product and service offerings, or when integrating output devices from disparate vendors. What they can find is a great deal of feature disparity and overlap, and that problem increases as the number and variety of output devices in their plant increases. This can lead to unexpected or inconsistent output across their many installed devices.

In fairness to the DFE vendors, all of this was done with the intention of giving the user almost everything you would need when you purchase one of these output devices, and if you only have one device or one version of one brand, it could be exactly what you need. However if you have multiple devices, especially from multiple vendors—which is true in most plants today—it could present a problem. Many of the DFE vendors have recognized that the problems I have highlighted here do exist, and in an effort to address them, they have started to create bridge solutions, either as standalone applications or as a part of their DFE offerings. But does that really solve the problem? Stay tuned….

In the next article in the series, we will take a look at some representative examples of the RIP and DFE software available to support the output devices and their included workflows. We will look deeper into the problems that can occur when there is disparity and overlap of DFE features in disparate vendor solutions. We will also look at whether and how they support integration with the business and information management software we have previously discussed in this series.

Remember, if you have any topics you think are important and would like us to cover during the balance of this series, please let us know!