Fedora contemplates the driverless printing future

Posted Jun 6, 2021 1:54 UTC (Sun) by Paf (subscriber, #91811)
In reply to: Fedora contemplates the driverless printing future by knan
Parent article: Fedora contemplates the driverless printing future

I think the answer is basically “CUPS feels they need out of the driver game to make their architecture sane”. The move from drivers to printer apps seems in most ways like a significant step backwards.

Fedora contemplates the driverless printing future

Posted Jun 6, 2021 2:46 UTC (Sun) by pizza (subscriber, #46) [Link]

Consider this -- How does one print to a locally-attached printer from a container or sandboxed application?

The legacy CUPS model requires the printing stack (or at least one part of the "driver") to have root access, which rather defeats the point of sandboxing relatively untrusted applications.

CUPS isn't trying to "make its architecture sane" for its own sake; while it represented a vast improvement over what came before, the old approach has reached the end of its ability to grow/scale to meet current (much less future) needs.

(In many ways, this is similar to the X11 -> Wayland transition -- except nearly every printer manufactured for the past decade is already Wayland-native, and these "printer applications" are akin to XWayland to allow older printers to keep working)

> The move from drivers to printer apps seems in most ways like a significant step backwards.

Not from a typical end-user's perspective.

Fedora contemplates the driverless printing future

Posted Jun 6, 2021 7:50 UTC (Sun) by smurf (subscriber, #17840) [Link] (4 responses)

It's not, though, because priter apps afford far better integration.

Consider a USB-connected label printer. It supports wildly disparate cartridges for different sizes (or even endless w/ cutter). You typically ask the printer what's loaded right now, then send it an appropriate bitstream of things to print.

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".

CUPS as it is now is unable to support any of this because the printer driver simply reads Postscript on stdin and sends the raster data to stdout, which another printer-agnostic driver feeds to USB. CUPS thus can only blindly send the data stream to the printer: the printer reports an error, the print job is lost and the printer is wedged and needs to be power cycled. Bah. Even if you got rid of the USB driver you still can't reflect the printer state in your print dialog.

Fedora contemplates the driverless printing future

Posted Jun 6, 2021 12:23 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

> CUPS as it is now is unable to support any of this because the printer driver simply reads Postscript on stdin and sends the raster data to stdout, which another printer-agnostic driver feeds to USB. CUPS thus can only blindly send the data stream to the printer: the printer reports an error, the print job is lost and the printer is wedged and needs to be power cycled. Bah. Even if you got rid of the USB driver you still can't reflect the printer state in your print dialog.

For a very long time, (15+ years) CUPS has provided a backchannel and standardized ways to query and percolate media type, status reporting, and whatnot up through the stack (including providing info that UIs could use to restrict option selections to valid combinations) but in practice very few drivers ever properly implemented this, because it was complex (due to the very loose coupling between layers), brittle (again due to the loose coupling), and nearly zero UI/frontend support for this stuff.

This stuff is the main reason I'm looking forward to a native, end-end IPP printing flow. Printer Apps are more complex than an individual CUPS filter driver, but the bidirectional-from-the-start paradigm (unlike the largely fire-and-forget^H^H^H^H^Hpray model of yesteryear) affords far tighter internal integration, enabling considerably improved -- and vastly more reliable -- functionality.

(I say this as not only a heavy daily user of the legacy CUPS driver paradigm, but as someone who has spent nearly a decade writing CUPS drivers+backends and dealing with the endless support headaches. Many of the recurring pain points simply go away under this new Driverless paradigm -- but in the mean time, suffice it to say there's a ton of bailing wire, duct tape, and goat blood barely holding the creaky mess together, and users still have to bypass CUPS altogether for common management/maintenance tasks)

Fedora contemplates the driverless printing future

Posted Jun 6, 2021 13:41 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

Well, apparently nobody knows about this (certainly not the authors of the P-Touch driver). Also even if known, the standard architecture of separate CUPS-raster-device filters doesn't accmodate any back channel, so no wonder nobody implements it. Too much work.

Fedora contemplates the driverless printing future

Posted Jun 7, 2021 19:13 UTC (Mon) by pizza (subscriber, #46) [Link]

> 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

Posted Jun 7, 2021 18:19 UTC (Mon) by Wol (subscriber, #4433) [Link]

> 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