Native CUPS rasterization works in two steps:
First is the
step. It uses the special CUPS
device from ESP Ghostscript 7.05.x as its tool.
Second is the
step. It uses various
device-specific filters; there are several vendors who provide good
quality filters for this step. Some are free software, some are
shareware, and some are proprietary.
Often this produces better quality (and has several more advantages) than other methods.
This is shown in
the cupsomatic/foomatic Processing Versus Native CUPS
Figure21.10.cupsomatic/foomatic Processing Versus Native CUPS.
One other method is the
way. Note that
made by the CUPS
developers. It is an independent contribution to printing development,
made by people from Linuxprinting.org.
is no longer developed, maintained, or supported. It now been
is a complete rewrite
of the old
idea, but very much improved and generalized to
other (non-CUPS) spoolers. An upgrade to
advised, especially if you are upgrading to a recent version of CUPS,
Like the old
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.
kidnaps the print file after the
stage and deviates it through the CUPS-external,
systemwide Ghostscript installation. Therefore, the print file bypasses the
filter (and also bypasses the CUPS raster drivers
). After Ghostscript
finished its rasterization,
hands the rendered file directly to the CUPS
cupsomatic/foomatic Processing Versus Native
CUPS, illustrates the difference between native CUPS rendering and the