Native CUPS rasterization works in two steps:

Often this produces better quality (and has several more advantages) than other methods. This is shown in the cupsomatic/foomatic Processing Versus Native CUPS illustration.

Figure21.10.cupsomatic/foomatic Processing Versus Native CUPS.

One other method is the cupsomatic/foomatic-rip way. Note that cupsomatic is not made by the CUPS developers. It is an independent contribution to printing development, made by people from Linuxprinting.org.^[6] cupsomatic is no longer developed, maintained, or supported. It now been replaced by foomatic-rip . foomatic-rip is a complete rewrite of the old cupsomatic idea, but very much improved and generalized to other (non-CUPS) spoolers. An upgrade to foomatic-rip is strongly advised, especially if you are upgrading to a recent version of CUPS, too.

Like the old cupsomatic method, the foomatic-rip (new) method from Linuxprinting.org uses the traditional Ghostscript print file processing, doing everything in a single step. It therefore relies on all the other devices built into Ghostscript. The quality is as good (or bad) as Ghostscript rendering is in other spoolers. The advantage is that this method supports many printer models not supported (yet) by the more modern CUPS method.

Of course, you can use both methods side by side on one system (and even for one printer, if you set up different queues) and find out which works best for you.

cupsomatic kidnaps the print file after the application/vnd.cups-postscript stage and deviates it through the CUPS-external, systemwide Ghostscript installation. Therefore, the print file bypasses the pstoraster filter (and also bypasses the CUPS raster drivers rastertosomething ). After Ghostscript finished its rasterization, cupsomatic hands the rendered file directly to the CUPS backend. cupsomatic/foomatic Processing Versus Native CUPS, illustrates the difference between native CUPS rendering and the Foomatic/cupsomatic method.