Rendering PostScript

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.
9 August 2013

Pages: 1 2 3

4 responses to “Rendering PostScript”

  1. Chai says:

    Hey, Hope you can read my message. I am really crazy about your article, which is the best one I have ever read in this year relating to RIP.
    I have a question. How to RIP handle the input file of bitmap already?

    Thanks very much

  2. Ailsa says:

    Excellent article – very informative.

  3. carl stella says:

    Our company designs & manufactures thermal printers for Aerospace Flight Deck operations. We are developing a 300 dpi monochrome 8.5 inch roll paper version based on a power p.c. processor & would like to have the ability to render Post Script 3 data received over the Ethernet Com Port.
    We are trying to use Ghost Script with limited success thus far. Can you recommend a consultant service in the Simi Valleyt, CA area or perhaps a ready to go RIP, which we can install in our design?

    • Laurens says:

      I only have experience with stand-alone RIPs, not with embedded controllers. I assume both Adobe and Global Graphics have a list of their OEM-partners on their sites. One of those might be offering just what you need.