On 6/3/18 5:24 am, David A. De Graaf wrote:
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.
Have you considered implementing the other Microsoft way, which I'm not
sure how to do as I'm not a network technician but which a number of
organizations tend to do, and that is when the client does a network
browse for network printers, selects the printer that they want to use,
the server downloads and installs the driver on the client machine?
Admittedly, this still requires the client to prepare the data for
printing, but at least the server or the printer itself handles the
queuing of print jobs.
regards,
Steve
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.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
