Fedora contemplates the driverless printing future

Posted Jun 4, 2021 20:40 UTC (Fri) by pizza (subscriber, #46)
In reply to: Fedora contemplates the driverless printing future by Paf
Parent article: Fedora contemplates the driverless printing future

> I’m still trying to understand why they’re called “printer applications”. It sounds like each and every one will need to be custom created. That sounds awful.

The old name for such things was "raster image processor"

But yes, in theory every individual printer could have a unique "application" which sounds awful until you consider that every printer already does have one, only it's embedded into the printer itself.

In practice, entire printer families will be supported by a single "printer application" -- eg any printer that speaks postscript and has a PPD is handled by ps-printer-app, dymo and zebra label printers work using lprint, and the (eventual) gutenprint printer app will handle 3500 or so separate models from multiple manufacturers.

> Why doesn’t splitting CUPS allow the “driver using” half of CUPS to serve as a *general* printer application? And why isn’t that the idea?

The simple reason is that CUPS is not structured to (easily) have multiple relatively ephemeral self-contained server instances running on a system, and restructuring it to do so is a substantial undertaking. (current) CUPS also only implements a subset of the IPP spec, and there's no way to automagically map the considerable breadth of individual printer functionality from PPD options to standard IPP attributes, so per-printer tweaks are all but guaranteed. Work is being done on all of these fronts.

Fedora contemplates the driverless printing future

Posted Jun 5, 2021 18:23 UTC (Sat) by Paf (subscriber, #91811) [Link]

Thank you - I can’t claim to understand all of this in any detail, but this is still very informative.

Fedora contemplates the driverless printing future

Posted Jun 5, 2021 18:30 UTC (Sat) by knan (subscriber, #3940) [Link] (8 responses)

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

And if this is something that needs to be compiled per os and arch, what exactly has been gained?

- snarky old fart

Fedora contemplates the driverless printing future

Posted Jun 6, 2021 1:54 UTC (Sun) by Paf (subscriber, #91811) [Link] (6 responses)

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

Fedora contemplates the driverless printing future

Posted Jun 6, 2021 21:49 UTC (Sun) by marcH (subscriber, #57642) [Link]

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