To CUPS or not to CUPS

Declan. Moriarty declan.moriarty at
Tue Jul 8 09:43:59 PDT 2003

On Tue, Jul 08, 2003 at 07:17:23PM +0600, Alexander E. Patrakov
enlightened us thusly
> 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).

Hmmm... I did a talk that was translated into English not that long
back. It has the russian & english one line each. It printed in (someone
else's) windows. I'll run it into my system and let you laugh at the 
results ;-).
> > 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).

Alexander, this is admirable and adds to the knowledge base. I am not
familiar with either foomatic or cups-o-matic, but remeber them vaguely
being touted as the best thing since sliced bread, and doing nothing for
my situation (non postscript printer, ps and other formats to print).

> > 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.

In case it escaped your notice, Alexander, I am probably the harshest
critic of cups on the list. I don't have it installed. But any exercise
that helps subsequent lfsers wishing to print to understand why their
newly compiled won't do the business is well worth the effort. I would
even install it in /opt (Otherwise empty :-D) for the purpose. I somehow
imagine that this would be better done by users than critics.

Doesn't the fact that we are contemplating this reverse engineering of
cups to assist in sorting the many problems on the list speak volumes
about the documentation, and the program? 

What would be ideal would be a test system. Anyone who had cups and
wasn't getting print would install a specific (Mythical) printer, and
trace the thing through themselves. Then those who see the value of it
would not have the same pain I did.

> > /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.
I did leave out most of the syntax. The above line is indeed crap. The
gs test is essential, however. In the pmr1, gs IS the print engine,
which adjusts the resolution, chooses the fonts, and adds the printer
characters. Any further processing, or any preprocessing for that
matter, is not required. As you describe it, cups performs the
unnecessary step of adding  characters to a postscript file before
piping it to ghostscript, which would have added them anyhow. There is a
networking/scheduling function of course.

> > 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.


	With best Regards,

	Declan Moriarty.
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