LWN: Comments on "Fedora contemplates the driverless printing future"

Fedora contemplates the driverless printing future

Wol — Sun, 22 Jan 2023 09:58:48 +0000

Is your new samba an upgrade? I remember ages ago something about upgrading the samba protocol (for security of course) and a lot of old printers can't upgrade.

If you've got a new samba config, you might find it needs SMBv1 or somesuch for the printer, and that is almost certainly "disabled by default" for being insecure.

Cheers,
Wol

Fedora contemplates the driverless printing future

SDRiches — Sun, 22 Jan 2023 00:28:36 +0000

Just installed Fedora 37 and am now trying to print to my 15 yr old Samsung ML-2240 with IPP, attached to a DNS-320 NAS via usb. NAS works fine - printer - no worky. Worked fine for years under Fedora 27 smb://192.168.2.16/lp (cifs). When I migrated to Fedora 37 I also changed to NFS from CIFS and changed the printer setup accordingly to IPP to get off the old netbeui stuff. IPP all new to me. Anyway so I went back to cifs for the nas and back to samba for the printer - printer still no worky! The only way I can print is from my home theatre pc running Fedora 27 - thats awkward (not intended for typing) but at least it works!
So maybe time for a new printer and then I read all this about IPP and print everywhere and all bets off! Are we going back in time?

Fedora contemplates the driverless printing future

jezuch — Thu, 24 Jun 2021 17:56:13 +0000

What times we live in - a desktop machine today needs to be way beefier than a server! 🙃

Fedora contemplates the driverless printing future

malor — Sun, 20 Jun 2021 18:17:19 +0000

The Pi 4B is particularly impressive. That sucker has quite a lot of CPU, and a fair bit of I/O power. It's not quite fast enough to make a very good desktop, at least running Ubuntu, but it's a killer little server box. Most Unix-style server apps were written a great long while ago, aimed at machines far less powerful, so you can load up a 4B with a fair number of daemons and expect it to run very smoothly.

Fedora contemplates the driverless printing future

Jonno — Sat, 19 Jun 2021 10:30:35 +0000

> How do you set up a printer with a non-ambiguous name, other than - for every PC! - editing the queue name and swearing when Windows promptly forgets it next time it does a discovery ...

You do the change *on the printer*, not in Windows. Some printers have a small LED screen and navigation buttons, others have a built-in web-server, others have both. Find the "Network Identification" section and change "Host Name" and "Bonjour Service Name" to whatever you want. ("Host Name" is passed to your DHCP server, which may be configured to set up a DNS record with that name in your local domain. "Bonjour Service Name" is the mDNS name the printer will advertise itself under.)

Fedora contemplates the driverless printing future

Wol — Sat, 19 Jun 2021 01:59:40 +0000

> > If a PC searches for all IPP printers it will have a large list of them. If it's configured by an administrator, it'll only have one or two.

> BTW, I was referring to the "administrator" configuring the printer itself to have a non-ambiguous name instead of whatever the printer was shipped with. This is routine for any organization large enough to have more than a couple of printers.

Yes I'm talking about a home setup, so maybe three printers is a lot, BUT. How do you set up a printer with a non-ambiguous name, other than - for every PC! - editing the queue name and swearing when Windows promptly forgets it next time it does a discovery ...

> > We've got THREE printers. Yet the printer list on Windows has maybe TEN printers listed? How am I supposed to get rid of the printers I don't want to be visible? They are a real pain.

> I can't help you there, beyond stating the obvious point that for that to have happened, Windows had to have been explicitly set up that way.

So how come I did NOT explicitly set anything up like that, yet Windows does it anyway?

My Windows settings are the DEFAULT. With the result that our main printer appears under about three different names - the one it gave itself, the one I tried to give it, and the one I explicitly edited on the PC. (At which point, the original name I edited promptly reappeared as a new printer...) Our secondary printer is just as bad. Plus all the special Windows printers half of which I'd like to delete ...

BY DEFAULT, Windows searches for AND DISPLAYS, every printer it can find. And on a halfway large network, that's likely to be A LOT.

Cheers,
Wol

Fedora contemplates the driverless printing future

zlynx — Sat, 19 Jun 2021 01:58:43 +0000

The large lists of printers problem is caused by everyone being too helpful. The printers support multiple print and automatic discovery protocols. And the operating systems add support for more discovery protocols.

The end result can be one printer showing up anywhere from one to six times.

I remember the bad old days though, where it was sometimes a major effort to get a printer onto the network even one time. So this is a better problem in its own way.

Fedora contemplates the driverless printing future

pizza — Sat, 19 Jun 2021 00:58:38 +0000

> If a PC searches for all IPP printers it will have a large list of them. If it's configured by an administrator, it'll only have one or two.

BTW, I was referring to the "administrator" configuring the printer itself to have a non-ambiguous name instead of whatever the printer was shipped with. This is routine for any organization large enough to have more than a couple of printers.

> We've got THREE printers. Yet the printer list on Windows has maybe TEN printers listed? How am I supposed to get rid of the printers I don't want to be visible? They are a real pain.

I can't help you there, beyond stating the obvious point that for that to have happened, Windows had to have been explicitly set up that way.

> Or, in the business environment, how do you stop the CEO accidentally printing confidential documents on the post room printer (or the office boy printing his love letters on the CEO's printer :-)

Duh, the same way it's done currently -- have the administrator configure the CEO's system to only print to a specific subset of printers -- by setting up explicit printer queues and disabling auto-discovery. And/or having the C-suite computers/printers on their own private network segment, which is a good idea regardless.

> Made worse by the modern Windows habit of changing the default printer to whatever you used last ... so as soon as you've lost one document, you promptly lose ALL your documents.

That hasn't been my experience, but in the end, there's only so much one can do about systems that insist on doing the wrong thing.

> This is FUNDAMENTALLY different from before, when you could EASILY configure any PC to only know about one or two printers.

I'd disagree about the "easily" part, but literally nothing has changed on that front. One can still create local print queues pointing at whatever remote printer you want (Driverless IPP or IPP, JetDirect, Windows, CUPS, whatever) and completely disable auto-discovery. That functionality is not going away.

Fedora contemplates the driverless printing future

Wol — Sat, 19 Jun 2021 00:21:35 +0000

> > The result is that in large organizations where people can get printers in their offices when you try to print you often see endless lists of printers all with more or less the same name apart from some obscure hash and there is apparently no way to filter them out.

> This is effectively no different than before, and the solution is the same -- administrators have to pick a printer name that is unambiguous.

You're missing something ...

If a PC searches for all IPP printers it will have a large list of them. If it's configured by an administrator, it'll only have one or two.

We've got THREE printers. Yet the printer list on Windows has maybe TEN printers listed? How am I supposed to get rid of the printers I don't want to be visible? They are a real pain.

Or, in the business environment, how do you stop the CEO accidentally printing confidential documents on the post room printer (or the office boy printing his love letters on the CEO's printer :-)

Made worse by the modern Windows habit of changing the default printer to whatever you used last ... so as soon as you've lost one document, you promptly lose ALL your documents.

This is FUNDAMENTALLY different from before, when you could EASILY configure any PC to only know about one or two printers.

Cheers,
Wol

Fedora contemplates the driverless printing future

pizza — Fri, 18 Jun 2021 14:11:13 +0000

> The result is that in large organizations where people can get printers in their offices when you try to print you often see endless lists of printers all with more or less the same name apart from some obscure hash and there is apparently no way to filter them out.

This is effectively no different than before, and the solution is the same -- administrators have to pick a printer name that is unambiguous.

> In many cases, the number of configurable features that one gets when using an old style printer driver is vastly superior to what you get via the driverless printing. Or the other way round, the degree of configuration that you can apply when printing in the driverless way is often insufficient for anything but the casual output of a printed page.

There's no inherent reason why the options exposed via IPP have to be any more limited than the options exposed via a native driver, but ultimately gets presented to the user is up to the IPP print client. (Right now the least common denominator seems to be the subset of IPP that AirPrint and Mopria require for certification)

Fedora contemplates the driverless printing future

callegar — Fri, 18 Jun 2021 13:43:03 +0000

From a user perspective there are a couple of serious (though hopefully solvable) issues with the driverless printers as of today.

One of them is related to the "pollution" of the printers list.

For most printers supporting IPP the configuration of who the printer should be advertised to is either impossible or so indiscoverable to be practically impossible to most users. The result is that in large organizations where people can get printers in their offices when you try to print you often see endless lists of printers all with more or less the same name apart from some obscure hash and there is apparently no way to filter them out. Maybe this may also imply that in many cases people print by mistake to someone else printer with an obvious waste of paper and at times the uncontrolled spread of sensitive information.

The second issue is printer configuration.

In many cases, the number of configurable features that one gets when using an old style printer driver is vastly superior to what you get via the driverless printing. Or the other way round, the degree of configuration that you can apply when printing in the driverless way is often insufficient for anything but the casual output of a printed page.

Fedora contemplates the driverless printing future

scientes — Thu, 17 Jun 2021 04:57:07 +0000

Maybe we use old printers because the ink cartridges get smaller with every generation.

Fedora contemplates the driverless printing future

JanC_ — Tue, 15 Jun 2021 20:27:01 +0000

gLabels allows you to select what labels on e.g. an A4 sheet with 10 labels to print on (or which one to start printing on, in case you print multiple pages), so I'm not sure what you mean by “waste”?

while SUSE/openSUSE don't advertise their "IPP Everywhere" support, the command line should just work

drpatricko — Tue, 15 Jun 2021 05:30:52 +0000

Indeed, ipptool and driverless CUPS backend are packaged and available on openSUSE and SUSE. There's just not much to advertise yet.

I see at least one SUSE employee active in upstream CUPS discussions, I am sure we are not being "left behind".

Fedora contemplates the driverless printing future

farnz — Mon, 14 Jun 2021 10:16:11 +0000

Couple of reasons:

Many printers have PPDs that translate a subset of their IPP Everywhere capability to an old-style PPD for CUPS on macOS. My HP does, for example. You'd need to identify these PPDs and ignore them completely - which is a mostly manual process to begin with, and is best done by the person who wrote the PPD.
Ignoring the automatic reuse of existing PPDs, that's what the PAPPL project provides. It's a library for taking CUPS raster drivers and matching PPDs and producing printer applications.

Basically, doing a good job of an application that supports existing PPD files and the matching CUPS raster drivers is an engineering effort on a par with using PAPPL to write printer applications for those printers that don't do IPP Everywhere already.

Fedora contemplates the driverless printing future

cpitrat — Mon, 14 Jun 2021 07:34:44 +0000

But why not create a printer application that supports existing PPD files and even automatically find the one installed in the previous CUPS version so that this is transparent to all users?

Fedora contemplates the driverless printing future

pizza — Sun, 13 Jun 2021 22:51:50 +0000

Any printer that can hold more than about 50 sheets of paper still tends to use a removable tray to hold said paper -- that tray is the paper cassette. The Brother laser I have here holds about 250 sheets in its cassette, with the option of using high capacity cassettes that can hold an entire ream (500 pages) at a time.

(I also have several Canon and Kodak photo printers that also use removable paper cassettes...)

Fedora contemplates the driverless printing future

Wol — Sun, 13 Jun 2021 21:37:15 +0000

I dunno ...

We always just put a box of paper underneath the printer. Okay, we didn't have the super-fast chain printers, but once I persuaded my boss to replace the dot-matrices with proper line printers, they could certainly fly through a box with ease ...

Cheers,
Wol

Fedora contemplates the driverless printing future

amacater — Sun, 13 Jun 2021 21:12:55 +0000

I suspect it's the plastic casing that holds a huge amount of fanfold paper to run through - the equivalent today would be the tray holding individual sheets on a larger laser printer. Particularly with fanfold, you wouldn't want it to unfold until you were ready.

Fedora contemplates the driverless printing future

nix — Sun, 13 Jun 2021 20:05:00 +0000

I didn't -- but it turns out to be in the Wikipedia article on this error (because of course there is one). It stands for "Paper Cassette", of course, because *obviously*. (What sort of historical artifact a "paper cassette" might be, I have no idea.)

while SUSE/openSUSE don't advertise their "IPP Everywhere" support, the command line should just work

ddevault — Sat, 12 Jun 2021 20:12:14 +0000

Huh. I had never heard of IPP Everywhere. A few weeks ago I spent several hours trying to get a traditional printer driver to work before giving up. After reading this article, I tried IPP everywhere and was holding a test page in less than 5 minutes. Thanks for the tip.

while SUSE/openSUSE don't advertise their "IPP Everywhere" support, the command line should just work

susanne_eb — Thu, 10 Jun 2021 10:22:58 +0000

"IPP Everywhere" is just provided via a sufficiently current local cups package, which is also available for SUSE/openSUSE. They just don't advertise it in the documentation (which is a bummer).

https://build.opensuse.org/package/view_file/Printing/cup...

Fedora contemplates the driverless printing future

JanC_ — Wed, 09 Jun 2021 14:00:40 +0000

I have one of those Samsung printers too. Was really cheap to buy compared to competitors, and after a little bit of issues with the open source drivers early on it has worked quite nicely for whatever I need to print (which isn’t much these times, another reason why I’d rather not have to buy a new one…).

Fedora contemplates the driverless printing future

akumria — Wed, 09 Jun 2021 01:54:04 +0000

That is already being handled: https://github.com/alexpevzner/sane-airscan

it works pretty well for printers that implement either of the two standards (eSCL or WSD).

Fedora contemplates the driverless printing future

jafd — Mon, 07 Jun 2021 23:01:18 +0000

Whew!

Now in another 30 years, we're going to tackle scanners.

Oh deities!

Somehow even scanners that are said to work, don't quite work, and need proprietary binaries that will only work with a particular libc.so.6. They are being made by the same companies that gladly jump onto the driverless printing bandwagon, and I happen to own a beautifully schizophrenic multifunction unit whose printer is "driverless" and just works, while the scanner part works not at all even on macOS (because its stupid app suite — scanners always come with stupid apps — are 32-bit-only).

Fedora contemplates the driverless printing future

marcH — Mon, 07 Jun 2021 20:55:42 +0000

> PS. claiming "localhost" is on the network is kind of a pointless thing.

localhost is the special "network" with a single host and it's not "pointless": high-level printing protocols (just like most TCP/IP protocols) don't want to know which particular networks your printer is connected to. It's much simpler when "everything is a network" and networking implementation details and choices stay private to you.

Fedora contemplates the driverless printing future

pizza — Mon, 07 Jun 2021 19:13:35 +0000

> Also even if known, the standard architecture of separate CUPS-raster-device filters doesn't accommodate any back channel, so no wonder nobody implements it.

IIRC the CUPS backend API [1] has always [2] supported a backchannel. But it's not guaranteed to be present/functional [3], so individual filters/divers rarely utilized it -- Ironically, most of those that did were proprietary drivers for MacOS.

[1] https://www.cups.org/doc/man-backend.html
[2] It was present in v1.1, released over 20 years ago. I didn't bother to look further back.
[3] The humble PC parallel port wasn't necessarily bi-directional. The same is still true for USB printer class devices. We're still hobbled by this baggage.

Fedora contemplates the driverless printing future

Wol — Mon, 07 Jun 2021 18:19:27 +0000

> Now a sane workflow would be "people send whatever print jobs to this printer, it pops up some dialog which cartridge you should insert next, then prints all jobs for that cartridge. Repeat". Or "you have three printers with different cartridges. The print dialog shows which one is loaded with what. You send the job to the appropriate printer".

This sounds like the spooler I was dealing with DECADES ago in the early 80s.

Although I think you needed to create multiple queues for the different configurations, and you'd stop the current queue, change the configuration, and activate the new queue. You CAN sort-of do that with windows, but it's not particularly easy ...

Cheers,
Wol

AppleTalk FTW

pizza — Mon, 07 Jun 2021 16:52:32 +0000

> I'm referring mainly to printer local discovery, which was what Avahi/Zeroconf/etc have been trying to re-create for a while now.

Sure, appletalk worked great... as long as you were using all-apple stuff. Windows discovery worked reasonably well.. as long as everything else was running Windows too. CUPS's local discovery worked equally well.

They all fell flat on their faces when you needed to cross ecosystems and the printer didn't speak a standard PDL (like postscript or HP-PCL)

> I'm not sure I trust the current desktop decision makers to take the latter property into account, given the last decade+ of Freedesktop decisions.

The "current desktop decision makers" (including Freedesktop.org) have nearly nothing to do with the standards and decisions of the OpenPrinting/PWG and IPP.

Fedora contemplates the driverless printing future

gnoutchd — Mon, 07 Jun 2021 16:49:37 +0000

No, pizza understood you perfectly. "On the network" in this case means "reachable by code that knows how to open an AF_INET socket". There's no reason that can't be a local USB-connected printer as long as you have a driver that binds to a port on localhost and speaks the same protocol that a network printer would speak. ipp-usb is exactly that for any printer that supports IPP-over-USB, a standard widely implemented by modern printers. It's installed and enabled out-of-the-box by current or upcoming distro releases.

AppleTalk FTW

jccleaver — Mon, 07 Jun 2021 15:17:32 +0000

> Apple handled all of this so well that nearly every release of OSX required changes to printer drivers in order for existing printers to remain useful.

You can go much further back than that. I'm old enough to remember System 6.0.8 having to be released solely because System 7's were incompatible with the previous ones and would force resets whenever a printer had to go back and forth between 6 and 7 users.

I'm referring mainly to printer local discovery, which was what Avahi/Zeroconf/etc have been trying to re-create for a while now.

I get the desire to press ahead with new printers in a new way, but as someone else wrote, there are the disposable printers you replace every 2 years, and forever printers that have been in service for decades. I'm not sure I trust the current desktop decision makers to take the latter property into account, given the last decade+ of Freedesktop decisions.

Older printers' support

mchehab — Mon, 07 Jun 2021 10:45:52 +0000

> But for Hewlett Packard MFP1132… this is basic home printer with a scanner, nothing fancy. I'm surprised it isn't in 98%.

Those cheap USB-only laser scanner/printers don't have IPP natively. I have one such printer too, as the cost per page on such devices is very low.

Using it as a network printer is tricky, as the default support via hplip requires a proprietary x86-only driver, which require upgrades almost every time CUPS is upgraded. Also, as it is x86-only, one can't use a cheap arm device like RPi to be a printer server, and, last time I checked, the alternative of using foo2zjs driver won't provide sane support over the network.

AppleTalk FTW

pizza — Mon, 07 Jun 2021 10:27:46 +0000

> It amazes me how much modern strife in the Linux world consists mostly of people trying to re-implement stuff Apple Computer handled pretty well by 1989 and only needed a few later tweaks to reduce chattiness.

Apple handled all of this so well that nearly every release of OSX required changes to printer drivers in order for existing printers to remain useful.

> I'm leery of efforts to remove simple, hard-configurable systems.

It turns out those "hard-configurable" systems weren't so "simple" after all.

> And if we have to keep drivers around to not require another five services on a simple Linux device that just needs to spit out some lp data,

Printing hasn't been a matter of "simply spitting out some lp data" since before "line printer" ceased to be a meaningful term in of itself.

Fedora contemplates the driverless printing future

abbe — Mon, 07 Jun 2021 05:13:35 +0000

Maybe missing the firmware[0] ?

[0] https://github.com/koenkooi/foo2zjs

AppleTalk FTW

jccleaver — Mon, 07 Jun 2021 04:59:27 +0000

It amazes me how much modern strife in the Linux world consists mostly of people trying to re-implement stuff Apple Computer handled pretty well by 1989 and only needed a few later tweaks to reduce chattiness.

While Avahi/Zeroconf/Bonjour and all intended replacements may be appropriate for distributions, I'm leery of efforts to remove simple, hard-configurable systems. And if we have to keep drivers around to not require another five services on a simple Linux device that just needs to spit out some lp data, I'm not sure I have a problem with that.

Fedora contemplates the driverless printing future

ccchips — Mon, 07 Jun 2021 02:10:10 +0000

I'd be interested to know if there are any one-up labels (4" by 1" for instance) suitable for inkjet printers. Haven't found anything like that on Amazon yet...

Fedora contemplates the driverless printing future

marcH — Sun, 06 Jun 2021 21:49:58 +0000

> So this is just a rebranding and splitting from "driver" to "app" since that sounds cooler today.

That was my first impression too. Some comments here describe some tangible advantages of moving stuff around and changing abstraction layers beyond mere "coolness" (thx!) but I think a follow-up article could be easier to read than the comments in this one.

Fedora contemplates the driverless printing future

ccchips — Sun, 06 Jun 2021 18:20:30 +0000

I use gLabels for label printing, but again, what if I want to print 20 labels? I would have to scrounge up a dot-matrix printer or use a specialized label printer. I suppose I could get 1-up label sheets (if there is such a thing,) and it would be a little less wasteful....and what about the "driverless" problem with reverse-order-only printing? Envelopes are an absolute pain if I use that driverless thing.

But I do love gLabels and its capabilities...with the HPLIP driver!

Fedora contemplates the driverless printing future

mike.cloaked — Sun, 06 Jun 2021 18:06:51 +0000

This is also a good starting point: https://wiki.gentoo.org/wiki/Driverless_printing

Fedora contemplates the driverless printing future

JanC_ — Sun, 06 Jun 2021 15:56:25 +0000

You might also want to try gLabels for label printing.