On 03/03/18 20:20, Stephen Morris wrote:
On 3/3/18 9:01 am, David A. De Graaf wrote:
The cups system in Fedora 27 has taken a giant step backward from
prior versions in that browsing no longer works automatically. In
F26, if the cups-browsed service was enabled and started, all the
printers on the LAN would be discovered and be available for use -
automatically.
Hi David,
I'm a little confused by what you mean here. In all versions of
cups, including F27, when you add a printer to cups, if the network
printer is turned on cups can automatically find it if it has support
for the printer, then when that printer is selected and the driver
selected, the printer is added to the printer list.
The term "network printer" has (at least) two meanings. For you, I
suspect, it means a printer that is directly accessible on the LAN with
its own IP. It has enough internal memory to store some arbitrary
number of jobs enqueued to be printed when the printer manages to get to
them. Every computer on the LAN can send jobs directly to the printer
with the expectation that interfering traffic will somehow be resolved.
In addition each computer must be trained to know the idiosyncrasies of
that computer in the form of a "driver" designed specifically for that
printer. Jobs must be prepared at the sending computer to be agreeable
to that specific printer's needs. This is the Microsoft way.
For me, a UNIX traditionalist, a "network printer" is available to any
computer on the LAN, but ONLY through the intervention of the server
that controls it. This includes printers that are, in fact, wired to
the server via USB, etc., as well as those with direct (but secret) IP
access. The server, usually with tons of memory to spare, can easily
accept jobs simultaneously from many senders and queue them. It also
can analyze the file content sent, and filter it appropriately. Only
the server computer needs to know the details of how to actually prepare
the job for successful printing; the clients simply send print jobs to
the server and let it figure out the details. This is the *NIX way.
It is the second configuration that is getting short shrift in the
latest cups development. It seems perfectly obvious that when a server
"advertises" a printer's services, that each and every client should see
that service queue automatically. That's the very essence of the job
that cups-browsed is created to do. And it is what the newest version
fails utterly to do, unless the config file is edited as I described.
The F26 version worked perfectly, exactly as I expected, so it is possible.
One of my two printers is a bit rare and exotic. It is a Brother
HL-L8250CDN color laser printer, and is totally unknown to Fedora (and
to Windows). Fortunately, Brother has prepared installable .rpm files
with the necessary drivers that I have downloaded and installed on the
server computer. They work perfectly. But, considering all that
trouble, why in the name of God, would I want to repeat that effort for
each and every client computer that might want to use that printer?
That's just insane. But that's the Microsoft way.
If cups-browsed is active then another entry is automatically added.
In my case, with the Epson printer (Expression ET 3700) I have cups
finds two entries provided from having installed the Epson supplied
driver (cups doesn't have native support), one using lpd and the other
using dnssd. The entry that gets auto added if cups-browsed is active
uses ipps and is specified as driverless, hence when selecting paper
types it doesn't know anything about Epson specific paper.
regards,
Steve
In F27 this no longer works. But there is a workaround.
I must now edit /etc/cups/cups-browsed.conf on each and every client
machine to add these lines:
BrowsePoll datium
BrowsePoll datair
LocalQueueNamingRemoteCUPS RemoteName
where datium and datair are _my_ servers with connected printers.
Note that Fully Qualified Names, such as datium.datix.lan, are NOT
acceptable. With only two physical printers and a handful of client
machines on my LAN, this is marginally tolerable; with a much larger
LAN, it isn't.
I've complained in
https://bugzilla.redhat.com/show_bug.cgi?id=1518415 and in
https://bugzilla.redhat.com/show_bug.cgi?id=1525937.
Apparently the "upstream" developers have a much different view than
me of why Linux printing has traditionally been so successful and
reliable and are hell-bent on "fixing" it.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad@xxxxxxxx www.datix.us
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
