To CUPS or not to CUPS

Alexander E. Patrakov semzx at
Tue Jul 8 06:17:23 PDT 2003

On Tuesday 08 July 2003 15:21, Declan. Moriarty wrote:
> I've been lurking and reading. Allow me to apologise for the obvious
> offence caused by my rabid feelings about cups.
> It seems clear to me that those with happy cups experiences mainly seem
> to have postscript printers. If I had a postscript printer, I'd have
> been happy with it - It would have seemed easy to set up, reliable, etc.

Wrong for Russia, because most PostScript printers don't have Cyrillic fonts 
built in. I will take my words back if someone points me to a generic font 
embedding utility (must take PostScript on stdin, embed all fonts specified 
in the configuration file or by similar means, and output the PostScript file 
with embedded fonts on stdout).

> As it is, you got the pmr version 1 instead. And it was a minority
> report - for non postscript printers (1st sentence IIRC). I had wasted
> the Christmas holiday compiling it and ghostscript, trying every
> conceivable driver and setting, and all I got was 100 test pages of
> crap.
> For the uninitiated, can anyone demistify cups?

I will try. Note that I never used foomatic and/or cups-o-matic. Also note 
that the situation of non-postscript input fie is not covered here.

The input file is first processed by pstops filter, which embeds commands for 
setting resolution, color depth, media size and all bunch of other parameters 
as described in the ppd file specific to the printer. Then the output is 
passed to ghostscript.

CUPS by default (i.e. without foomatic) does not use any drivers built into 
ghostscript except a special "cups" driver. This driver understands special 
PostScript commands for setting resolution, color depth and similar settings, 
that were embedded by pstops. It outputs a raw raster (bitmap is the proper 
word in the Windows world) with a small header specifying the resolution, 
color depth, dimensions of the raster, and other parameters.

By default, it is NOT ghostscript's job to convert this raster to printer 
commands. You need either to kidnap PostScript from the conversion to raster 
(that's done by foomatic) or to supply a conversion tool that takes the 
raster as input and produces printer commands on output (that's done by 
gimp-print, it's a pity gimp-print is not in the book - please file a bug if 
you agree).

The resulting commands are then sent to a parallel, serial, USB, (with filters 
that don't come with CUPS - also SAMBA, FAX and other types of ports).

> in an explicit fashion that will allow
> someone with an installation that doesn't work to test the various bits?

In the next mail, if you request that (BTW, try to experiment yourself first). 
To get the idea: we will replace CUPS filters by shell scripts that call the 
original filters and tee the output to files in /tmp, and then we will 
examine each file in /tmp.

> /dev/lp0', kernel config, 'gs > /dev/lp0', and a2ps > dev/lp0, but when
> we give everything to cups, we can't check what it does. Either it comes
> out the other end or it doesn't. The web interface finds nothing.

As you can see from the above, the gs test really tests nothing.

> In the event of ghostscript using it's ppd file to write output
> for the printer, why does cups need a ppd? If it uses a2ps, why does it
> have ascii to ps filters itself?

The ppd file is read by pstops filter only. Ghostscript reads its results as 
special commands embedded in the PostScript file. a2ps is never used.

> People can explain operation with every reliable program. As soon as
> something stops working, you can get it, make a few tests, and find the
> broken link in the chain. This feature seems lacking with cups. Hence
> the mixed opinions.

Alexander E. Patrakov

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list