Originally PPDs were meant to be used for PostScript printers only. Here, they help to send device-specific commands and settings to the RIP, which processes the job file. CUPS has extended this scope for PPDs to cover non-PostScript printers too. This was not difficult, because it is a standardized file format. In a way it was logical too: CUPS handles PostScript and uses a PostScript RIP (Ghostscript) to process the job files. The only difference is that a PostScript printer has the RIP built-in, for other types of printers the Ghostscript RIP runs on the host computer.

PPDs for a non-PostScript printer have a few lines that are unique to CUPS. The most important one looks similar to this:

*cupsFilter: application/vnd.cups-raster  66   rastertoprinter

It is the last piece in the CUPS filtering puzzle. This line tells the CUPS daemon to use as a last filter rastertoprinter . This filter should be served as input an application/vnd.cups-raster MIME type file. Therefore, CUPS should autoconstruct a filtering chain, which delivers as its last output the specified MIME type. This is then taken as input to the specified rastertoprinter filter. After the last filter has done its work ( rastertoprinter is a Gimp-Print filter), the file should go to the backend, which sends it to the output device.

CUPS by default ships only a few generic PPDs, but they are good for several hundred printer models. You may not be able to control different paper trays, or you may get larger margins than your specific model supports. See Table 21.1 ??? for summary information.