To CUPS or not to CUPS
declan.moriarty at ntlworld.ie
Tue Jul 8 02:21:10 PDT 2003
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.
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?
Can anyone lay out exactly what cups does as it prints on to a sheet of
paper? Not vague terms, but in an explicit fashion that will allow
someone with an installation that doesn't work to test the various bits?
If someone can do this, please undertake it urgently.We can test 'echo >
/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.
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?
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.
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