[sf-lug] CUPS (was: Xsane can't see ...) printer

[Rick Moen]

Quoting Akkana Peck (akkana at shallowsky.com):

> Interesting information! When I was researching the printer before
> buying, what I found was admittedly mixed, but I couldn't find any
> other printers that weren't vastly more expensive that looked like
> they had a higher chance of success.

IMO, either lack of an Openprinting.org page _or_ one disturbingly vague
_or_ one linking to an offsite page describing how to acquire
proprietary add-on drivers is a sign that this printer model should be
avoided (unless you happen to have reliable information to contrary from
elsewhere).

Certain things in printing are really good signs:

1. At least 1-2 MB of RAM.
2. Real PCL6 (not 'emulation').
3. Real PostScript (not 'emulation').
4. An ethernet port, not just 'wireless networking' as with the Brother
   HL-3170CDW's (I gather) default hardware configuration.  You'll 
   have noticed my point that _it appeared_ that the difficulties
   addressing this printer vanished with ethernet, and correlated with
   use of a non-standard direct-over-wireless printing protocols.

The Brother HL-3170CDW failed literally all of my above criteria 
(if I understand the bit about default networking hardware correctly). 

When you say 'vastly more expensive', the problem is that you were
buying in the category of 'colour laser printer', which inherently 
is substantially pricier than are B&W laser printers (not to mention
inkjet junk).  So, yes, sure, average-quality colour laser printers
cost.  _And_ IMO you should have wondered how _this_ printer managed to
be substantially cheaper than 95% of that product category.

The answer was sad but inevitable:  They hit a low pricepoint by
designing a substandard device that critically cut corners everywhere.
In that regard, the fact that technically it isn't even a laser printer
but rather an LED one is by far the least important matter (i.e.,
there's nothing wrong with using a moving bar of LEDs as a light source
to activate toner, instead of a laser), but _does_ highlight the 
manufacturer's overriding design objective being hitting bottom dollar.

> I'm sure that's true, but I'm not blaming CUPS for anything related
> to the manufacturer driver package. I'm blaming it for the failures
> of the Debian CUPS pages before I downloaded any manufacturer package.

I should have completed my thoughts about CUPS in the previous message,
but sent it before I could elaborate.  I'll fill in what I should have
said yesterday, now.

> - Why does CUPS offer three different choices for the Brother
>   HL-3170CDW if none of them work? 
> 
> - Why does CUPS include a choice claiming the printer will work
>   driverless if that's not the case?
> 
> - Why does CUPS list several different drivers with identical names
>   and no way to tell them apart?
> 
> - Why does CUPS auto-fill seven potential connection URLs for the
>   printer, none of which actually work to talk to the printer, yet
>   it won't give you a hint what it's actually looking for so you can
>   craft a working URL?

So, what I failed to mention is that, IIRC, CUPS itself does not furnish
printer filters ('drivers'), just a framework of a daemon and some
utilities into which various sets of filters can interact.  (My memory
on that point may be mistaken.)  There are a number of open source
filter packages commonly encountered and commonly installed, and those
are inevitably provided as separate packages.  The ones that comes to
mind off the top of my head are Foomatic, Gutenprint, and Ghostscript
Uniprint.

There are also a large assortment of other open source sets and
individual filters, and then also a motley crew of proprietary filters.
(There are at least two distinct categories of filters, raster drivers, 
and PostScript drivers.)

Warning:  I may be pretty vague and inaccurate in some details of what
I'm saying, because this is a whole specialty I seldom deal with, have 
forgotten most of what I _used_ to know, and haven't taken the time to
relearn it properly.

Anyway, IIRC the CUPS inventory of possible printer definitions includes
entries for at least some proprietary filters that may not lawfully be
distributed with Linux distros (without explicit licensing permission
from the stakeholders), as a convenience to users.  Without having seen
your installation's list, I would nonetheless speculate that the three 
entries for Brother HL-3170CDW are all of that nature -- stubs that can 
be _made_ to function by fetching and retrofitting the manufacturer code
(that the CUPS developers are aware of, but cannot be furnished with
CUPS).  

I don't know what specifically you mean by CUPS making a claim that a
printer will work driverless when that is not the case, so I cannot
properly comment.  I don't think there is such thing as 'driverless' 
in this context.  A CUPS printer object always requires use of a filter,
even if only a generic PostScript or PCL one.  You might mean without 
a _separate_ driver, in which case I would guess that the CUPS designers
figure it's up to you to figure out that a particular entry isn't going
to work until you've retrofitted a filter set available only from some
external source.  You could make a good argument that CUPS should be 
more informative, when that is the case, e.g. 'This entry isn't yet 
functional because the needed filter hasn't yet been installed.'

Why does CUPS list several drivers with identical names?  I'm guessing
that these were filters from different filter sets, and nobody at, say,
Foomatic bothered to ensure that their printer description for printer X
had slightly different wording from Gutenprint's description for the
same printer.  Lacking that differentiator, I guess what you'd need to
do is examine the particulars and see how they differ.

Why does CUPS offer to pre-populate seven different types of
connection to the printer without vetting that they work?  I guess
because making sure a particular printer is configured to, say, respond
to requests for lpd-type printing or IPP-type printing is a matter
specific to the printer and not even visible to CUPS let alone within
the scope of what CUPS sets out to do.

When I'm setting about to use a printer, the first thing I do is see if
it has an LCD-screen or equivalent and built-in controls for printer
configuration, wander through the screens to see what printing types
it's supporting, and, if possible, tell it to print out a page
describing its configured capabilities.  Most printers include this
feature.  (Some printers even annoyingly print out such a test page
every time they power up.)  Armed with that paper's information
including the printer's IP address (IMO, printers should be ethernet
devices, not appendages of some workstation connected over USB), only
_then_ do I go into CUPS configuration and enter my desired print
connection, usually lpd://e or ipp://.  Never Zeroconf/Bonjour (dnssd://
URIs).  Zeroconf is way too flaky -- and also clogs up your network with
wasteful broadcast storms all the darned time.  (Kill it with fire, I
say.  I'm very much with you on not using it at all.)