Posts Tagged ‘RIP’

  • How to grow with the RIP – David L. Zwang

    North American print expert, David Zwang, looks at the current state of the Digital Front Ends in the market, covering Digital Print DFEs as well as computer-to-plate DFEs, and the beginning of the plant production workflow, all with an eye toward building a flexible platform upon which to grow.

    In the last article, we looked at the basic structure and evolution of the DFE. Since it is functionally the controller for each piece of your print production equipment from proofers all the way up to production inkjet presses, it plays a critical role.

    However, the importance of that role is not just in how it controls the device and manages and prepares the incoming data, it is also critical in how it works with other DFEs in a plant production workflow. 

    Each device is shipped with a DFE from the device manufacturer. In some cases, like the Canon Océ PrismaSync, HP SmartStream, Kodak NexPress and Kodak 700, or the Xerox FreeFlow Print Servers, it is a DFE the manufacturer developed from the ground up and is used exclusively in their device product portfolio. In other cases, like the EFI Fiery Digital Print Server or the CREO Color Server, it is a universal DFE, and is customized to support each disparate manufacturer’s device features and requirements.

    As we discussed, at the heart of every DFE is an interpreter. All of the products listed above, except the HP SmartStream, are built on Adobe technology. The HP SmartStream is built on Global Graphics Harlequin technology, except for the HP Labels and Packaging Print Server which uses Esko FlexRip technology.

    The Harlequin RIP technology has been around since the late 1980’s. For many, it offered a competitive differentiation to the Adobe CPSI technology. Being a smaller company than Adobe, Global Graphics is able to react very quickly; in fact, usually faster than Adobe to changes in PostScript and PDF file format changes, even though Adobe created those file formats and the applications that created the files.

    According to the Global Graphics site, “The Harlequin RIP has processed PostScript files natively since 1988 and PDF files natively since 1997, including rendering of live PDF transparency since 2002.” The Harlequin RIP technology is not only capable of processing the same files as the Adobe technology, but in a recent test performed by RIT, it was found to be currently the fastest RIP technology on the market.

    Adobe OEMs, depending on the specific RIP, either use Adobe CPSI (Configurable PostScript Software Interpreter) only, APPE (Adobe PDF Print Engine) only, or a combination of both. As a refresher, CPSI is the primary software RIP that Adobe has been licensing since the early 1980’s. In fact, one of the first implementations was Scitex VIP (Visionary Interpreter for PostScript).

    This software is licensed in a SDK (Software Development Kit) that is composed of a lot of pieces of functionality that are assembled, integrated and configured differently by each OEM. Over the years, the OEMs have become very creative and have developed many value-added features to each of their implementations.

    Now, when PDF files are processed in a CPSI RIP they are first converted to a PostScript file stream, which can introduce some issues and variability, depending on the structure of the PDF file. In addition to the variability in implementations which can lead to differences in output of the same input file, many of the features found in PDF files are not natively supported. Image transparency is a perfect example of one of those features.

    The chances are, if you have a CPSI based DFE, you have probably already run into some problems with image transparency. Although some of the OEMs have developed significant workarounds to try to address some of those issues with their CPSI implementations.

    In 2006, Adobe introduced APPE to address those issues and more importantly to offer native support for processing PDF files. By using the same basic PDF library technology that is used in the Adobe Creative Suite to process the files, processing reliability increased dramatically. Since that initial introduction, continued APPE development has brought greater adoption, speed and increased feature support, including PDF/VT, which will be discussed later in the series.

    While some of the Adobe OEMs currently use either one of the core technologies or the other, some use a combination of both core processing technologies, as in the Fiery and CREO solutions. In those cases, they use a weighted decision-making system to determine which path the file takes.

    Although APPE is the newer and more ideal processing technology for processing PDF files, there are still cases beyond just PostScript files where CPSI is the preferred path in these systems. These cases include ‘value-added’ features and even some workarounds for a very few PDF transparency and file attribute issues.

    Before there were digital presses, there were CTP devices, and before that imagesetters (filmsetters). CTP devices still exist and probably will for a long time, since they produce plates for non-digital presses including offset, flexo and gravure. While I was previously discussing DFEs for digital print devices, the DFEs that drive CTP devices are very similar and in some cases identical.

    In fact, these were the developmental models for the digital print DFEs that exist today, so you will see many of the same features and even similar user interfaces. However, in the case of a CTP device, it is usually is making plates for many, if not all, of the presses on the floor, depending on the size of the plant.

    As a result, the DFE started to take on a new role as the hub of the plant production workflow for those print technologies. The CTP DFE was developed to support all of the relevant basic required features like file format support, preflight, interpreter, color management, trapping, screening, and device controls.

    When the CTP systems and their digital print offspring started to support digital presses, additional feature support was added to include basic imposition, soft proofing, JDF/JMF, and more recently layer management and VDP (Variable Data Processing), and the list of features keeps growing.

    Solutions like Agfa :Apogee Prepress, Fujifilm XMF, Harlequin (through OEMs), Heidelberg MetaDimension, Kodak Prinergy, and Rampage started to take the new role of CTP production hub more seriously. This expansion into capturing the management of the plant workflow began to present new efficiencies as well as new problems. And while it is nice to have a production management hub, what happens when you start to bring in disparate pieces of equipment from a variety of vendors? Is the feature redundancy of the multiple full featured DFEs a benefit or a does it create problems and workflow silos?

    In the next article we will look at the features, benefits, and issues that are associated with the expanded role of this new class of Workflow DFEs, as well as the entrance of the even newer specifically designed production management software solutions.

    David Zwang, travels around the globe helping companies increase their productivity, margins and market reach. With over 40 years of industry experience, David specializes in process analysis and strategic development for firms in the fields of publishing, design, premedia, and printing.

    You can contact David via email at david@zwang.com.

  • Catching the RIP – David L. Zwang

    The role of the RIP – also known as the DFE (Digital Front End) – is changing as a result of digital press technology and the shifting demands of the marketplace. US industry insider, David L. Zwang looks at the changing technology and how to build 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.

    David Zwang, travels around the globe helping companies increase their productivity, margins and market reach. With over 40 years of industry experience, David specializes in process analysis and strategic development for firms in the fields of publishing, design, premedia, and printing.

    You can contact David via email at david@zwang.com.