Rendering PostScript

PostScript is a language that describes the content of one or more pages. To actually use that description to print on paper or make a printing plate, a program is needed that interprets (or renders) the data, turning it into something that a printer, imagesetter or CtP system can output on media. This interpretation is done by a system that is called a RIP (Raster Image Processor) or renderer.

If every application on the market would use its own way of describing what the content of a page looks like, you would have to buy a RIP for every separate application (a QuarkXPress RIP, an Illustrator RIP, a Corel Draw RIP,..). To avoid this problem the input data are encoded in a standardized page description language or PDL. There are several PDLs. The most common ones are:

• PostScript (which is mainly used in graphic arts)
• PCL (for office use)
• HPGL (typically used to drive plotters for Computer Aided Design).

The remainder of this article focuses on PostScript RIPs.

Hardware versus software RIPs

In essence, a RIP is a software program running on some kind of computer. Twenty years ago, all RIPs ran on dedicated hardware, computers that were designed to only run the RIP software and that didn’t necessarily include a keyboard, screen or mouse. Such RIPs are called hardware RIPs. You can still find them in laser printers and other ‘cheaper’ devices. These build-in RIPs are also called PostScript controllers.

Nowadays a lot of RIPs run on generic PCs or Macs and behave just like any other application. These RIPs are called software RIPs. They may still include special hardware like a card to connect to the output device. To prevent piracy, software RIPs often include a security key like a dongle.

Adobe and not-so-Adobe PostScript RIPs

Since PostScript was developed by Adobe, they are the most important company creating PostScript RIPs. These RIPs are sold to the OEM market: Adobe create the core code of the RIP (which is nowadays called the CPSI or APPE in the latest generation) and sell it to any company looking for a PostScript solution. An imagesetter manufacturer then buys this code and adds both the necessary hardware to interface with their imagesetter and the extra software to control the software and add functionality.

Of course Adobe is not the only company that creates RIPs. Other companies have jumped on the bandwagon to create so-called PostScript clones. These are RIPs that conform to the Adobe PostScript standard. The most important ones are created by Global Graphics. Their RIP is called Harlequin and they also sell an alternative called the Jaws RIP. Ghostscript is a freeware PostScript interpreter from Alladin. Its commercial nephew is used in products like the popular BESTColor RIP.

Characterizing RIPs by their output

Another way of characterising RIPs is by looking at their output data:

• Some RIPs generate data that can be send straight to an imagesetter or plotter. For an imagesetter or CtP device these data are pixels that tell the laser inside the machine to either write or not write points on the media.
• Other RIPs generate an intermediate data format that still has to be processed by another system before being send to the output device. This allows the manufacturer to add an imposition system or for instance an editing workstation between RIP and imagesetter. Scitex and Barco RIPs are typical examples of such an approach.

Sending data to a PostScript RIP

In general every RIP receive data (pages encoded in PostScript or PDF), processes them and then sends the output data to their destination. The RIP software to achieve all of this is pretty sophisticated and at least as big and complex as a full blown office suite. There are various ways in which a RIP can receive its data. Let’s first take a quick look at how the data are created:

• You create a page in InDesign, QuarkXPress, Publisher or whatever and decide to print it.
• On a Mac, you go to the Chooser, select the LaserWriter driver and then select the device to print to. The LaserWriter is in fact a little application that is responsible for both the transfer of data to the selected medium and, depending on the application, the creation of PostScript data (see further).
• On a PC, you do basically the same thing. By selecting a printer, you tell the operating system which version of the PostScript driver can be called by an application to assist in the creation of a PostScript printfile.
• Some applications like Adobe Illustrator use PostScript as their internal format. This means they don’t have to do much work to create an output file, just add some stuff like dictionaries, font data and device dependent data like the screen ruling.
• Most prepress applications use their own unique internal data format and convert the page from this internal format to a PostScript file themselves. They can partly rely on the PostScript driver that is part of the operating system to handle part of this conversion.
• Business applications like MS Word or Excel completely rely on the PostScript driver to create the PostScript data. This means that by simply switching from one PostScript driver to another, you can get rid of some problems if they are related to a specific driver.

Once the PostScript print file is generated, it is forwarded to the selected medium or device. Most RIPs support a lot of different input channels.

• AppleTalk: a RIP can present itself on the network as if it is a laserprinter. A Mac user selects the RIP in the Chooser and prints to it. This is the easiest way of printing jobs but also a rather slow one.
• TCP/IP: RIPs can support either LPR, which is a standard Unix protocol, or the Helios streaming protocol. This means that you can print to a Helios EtherShare printer and this printspooler will forward the file to the RIP using the fast TCP/IP protocol.
• Named pipe: this is a Microsoft protocol to exchange data between different applications. It relies on TCP/IP for the actual transfer of data. This protocol can be used if you want to print from a PC to the RIP.
• Hotfolders: Most software RIPs can monitor several folders and process any PostScipt or PDF-file it finds in them. Just print your page to disk and put this PostScript file in a hotfolder. Hey presto, a couple of seconds later, the RIP notices the file and outputs it.

These are the most popular input channels but there are others as well. PostScript 3 RIPs can support a system called web-ready printing. This allows you to print to a RIP across the internet. Smaller devices such as laser printers may offer a USB connections.

In general, the more ways there are to send data to a RIP, the better you can integrate it in your existing (and future) workflow. Flexibility in input and output channels are at least as important as the performance of a RIP.

Once a RIP has received a PostScript file or PDF file, it can start processing that file.

In fact, this statement is not entirely true: for PostScript data, a RIP does not necessarily need the entire file. As soon as the data for the first page have arrived, the RIP can start digesting that page. For PDF-files this is not true. Due to the way PDF files are constructed, a RIP needs access to the entire file before it can start processing it.

Processing PostScript data

An Adobe RIP will first translate the content of the PostScript page into an intermediate format called the display list. The display list contains a description of the page at a more basic machine-level. So instead of using millimeters or points, all objects in the display list are positioned in device pixels.

All those objects are no longer TIFF files or EPS or fonts: the RIP also processes all the data within a page and, if necessary, converts them to an intermediate format and stores them in a so-called source list. Take fonts as an example: if you used a 20 point Avant Garde somewhere on the page, the RIP will take the outline data of the font (the printer font as Mac users call it), calculates how each individual character has to be output for that given size and resolution and stores these bitmap characters in a font cache. In PostScript Level 1, these font caches were stored permanently on disk. After a couple of days or weeks, they would take up so much room that the RIP lacked space to store other data. This would cause all kind of PostScript errors like “limitcheck” or “VMerror”. The user would then have to manually clean up all these temporary data by doing a “fontcache delete”. Adobe fixed this issue in PostScript level 2 where font caching is handled dynamically.

The RIP tries to keep both the display list and source list in main memory for as long as possible but it will store these data in a swapfile on disk if they become too large. Files containing lots of scanned images generate big source lists while files containing complex drawings from Illustrator or another application tend to generate big display lists. Of course a RIP will slow down if it has to access a slow hard disk instead of superfast memory. That’s why you see RIPs running on systems with 1 GB of RAM or more.

Once the display list is completed, the RIP will rasterize its content and send this bitmap to the output device. Some manufacturers add an extra step to this process and convert the display list to their own intermediate format. Scitex for instance used CT/LW as an internal format and added extra rasterboards to the imagesetter itself to perform rasterization at the last possible moment.

There is a general tendency to let the RIP handle additional tasks besides the stuff discussed above. Trapping can be such an option. Some manufacturers add impositioning software between the interpretation and rasterization of a file.

Output from the RIP

The rasterization process can be time consuming and result in a huge file that has to be send to the output device. Some RIPs will split these data up in small bands and send these to the imagesetter one by one, others save the entire bitmap to RAM or disk and then forward these data to the output device. Such an intermediate storage is called a frame buffer. All laser printers use such a buffer which is stored in RAM. This explains why complex pages may generate PostScript errors on a printer with limited memory: there simply isn’t enough RAM to store both intermediate data and the frame buffer.

The choice between output in bands and frame buffering is determined by the device that is attached and the workflow of the customer.

• Output in bands is the easiest way of communication between RIP and engine.
• Some imagesetter do not support “start-stop”. This means that they need all the data in one go without the slightest interruption (kinda like a CD-writer). For such systems a frame buffer has to be used.
• Frame buffers can also speed up the output process because the RIP can go on processing data while the engine is advancing the film, cutting it or waiting for the online processor.

The physical connection between the RIP and the engine is also of importance. There are various solutions used in the market.

• Many manufacturers use their own protocol and hardware to connect RIPs to their imagesetter. Agfa has its SCSI-like APIS-protocol. Scitex uses an optical connection between the two devices. Except for the newspaper market, there are no real standards.
• A standard network connection between RIP and engine can be used if the data transfer between the 2 devices does not exceed the capacity of a 10 or 100 Mbit line. This type of connection is often used for plotters.
• For cheaper printers and proofers, a USB connection can be used.