To CUPS or not to CUPS
Alexander E. Patrakov
semzx at newmail.ru
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
> 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
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 linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message
More information about the blfs-support