Rendering PostScript

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.

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.


Advertising