Printing is declining

Posted Jul 29, 2025 19:05 UTC (Tue) by WolfWings (subscriber, #56790)
In reply to: Printing is declining by jorgegv
Parent article: Help for OpenPrinting needed

And Brother printers also pretty much universally use generic IPP protocol so they require the least software of almost any printer on the market to print to. There's even lots of libraries to print directly for Python, Node, etc, no CUPS even needed the protocol is pure HTTP/HTTPs RESTful if a bit cumbersome at times.

Printing is declining

Posted Jul 29, 2025 21:08 UTC (Tue) by jengelh (guest, #33263) [Link] (11 responses)

>use generic IPP protocol so they require the least software of almost any printer

IPP is just transport/framing and not a magic bullet. Your printer still needs a certain format, so you need software almost all the time.
The least-software scenario is a print queue which forwards print jobs to another host without any conversion whatsoever.

Printing is declining

Posted Jul 30, 2025 6:20 UTC (Wed) by Wol (subscriber, #4433) [Link]

Like TCP/9100? Which I made much use of many moons ago ...

Cheers,
Wol

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 8:33 UTC (Wed) by farnz (subscriber, #17727) [Link] (9 responses)

New Brother printers are Mopria certified, which (for printing) is IPP with a specific format for document data, and a standard set of attributes so that the OS can determine the possible values of the free parameters in the format (paper size, feed trays, single sided, duplex long side, duplex short side, resolution, colour support etc).

As a result, the need for OpenPrinting is declining; many modern printers are simply "Mopria" printers from the OS point of view, because that gets you "free" driver support for Android, macOS, iPadOS and Windows.

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 11:28 UTC (Wed) by pizza (subscriber, #46) [Link] (8 responses)

> As a result, the need for OpenPrinting is declining; many modern printers are simply "Mopria" printers from the OS point of view, because that gets you "free" driver support for Android, macOS, iPadOS and Windows.

OpenPrinting isn't just about *drivers*; it is nearly single-handedly responsible for the IPP-based client infrastructure used to print from Linux, and that work is far from complete.

Additionally, Till is often the only non-proprietary-product-backed participant in printing standards bodies too.

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 13:42 UTC (Wed) by farnz (subscriber, #17727) [Link] (7 responses)

Sure, which is why I didn't say it's going away completely - just that the need for it is declining, because we're reducing down to "printing is PDF over IPP over either TCP or USB", instead of "printing is proprietary format over proprietary protocol over TCP or USB".

I do hope Till finds a new employer willing to pay so that Linux has great printing support - but that doesn't change the fact that OpenPrinting is less needed than it used to be.

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 17:38 UTC (Wed) by pizza (subscriber, #46) [Link] (6 responses)

> Sure, which is why I didn't say it's going away completely - just that the need for it is declining, because we're reducing down to "printing is PDF over IPP over either TCP or USB", instead of "printing is proprietary format over proprietary protocol over TCP or USB".

Unless of course you actually want to use a feature of the printer that's not (or badly) exposed via IPP, or your operating system's (or application's) IPP client doesn't support anything but basic option selection.

Conveniently, printer manufacturers all have their own proprietary, strings-attached apps for that, and heavily push for their use over using standard IPP/Airprint/Mopria clients.

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 17:53 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

That's where Mopria certification (and Apple Airprint) comes in - you cannot be Mopria certified if, for any feature Mopria has support for, you don't expose it fully over the standard mechanism. Do a bad job, and you're not certified.

And the cheap printers don't have features that aren't supported by Mopria, while the expensive ones tend to get it right because someone dropping $1,000 on a printer wants it to Just Work, dammit, and has the budget to match.

This does mean the printer manufacturer apps are doing a lot less than they used to - for the Mopria certified printer I have, all the HP app does is change the defaults. It's not in the printing path at all, and everything it changes is exposed properly over IPP (and changeable from Linux as a result).

Still leaves us needing OpenPrinting to keep the IPP side working well, but it reduces the need precisely because it's now PDF over IPP over TCP, not HP format over HP queueing protocol over TCP.

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 18:16 UTC (Wed) by pizza (subscriber, #46) [Link] (4 responses)

> you cannot be Mopria certified if, for any feature Mopria has support for, you don't expose it fully over the standard mechanism. Do a bad job, and you're not certified.

I own a couple of Mopria-certified devices that were Mopria-certified at launch yet out-of-the box didn't work with the official Mopria and standard IPP clients (ie anything other than than AirPrint-from-iOS).

(These blatant IPP compliance bugs were fixed in a subsequent firmware update, after which they _did_ work with the Mopria client...)

> This does mean the printer manufacturer apps are doing a lot less than they used

> Still leaves us needing OpenPrinting to keep the IPP side working well, but it reduces the need precisely because it's now PDF over IPP over TCP, not HP format over HP queueing protocol over TCP.

It's PDF-over-IPP as long as what you need is supported by the IPP path; otherwise you still need a "real" driver that speaks proprietary-over-IPP/USB.

(I'm not just talking out of my posterior here; drivers I have written still underpin numerous commercial IPP print servers)

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 18:30 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

For a lot of people, the IPP path supports everything they could possibly want, though. Why would I care about the proprietary format, or the proprietary transport protocol, when PDF over IPP works just fine?

And on the Microsoft side of the fence (which matters to a lot of printer vendors), the drive is towards Mopria as the only option, with printer vendors basically being locked out of providing proprietary formats without jumping through a lot of hoops (because MS have had some nasty security bugs caused by the means they use to let you go from Windows printing to proprietary formats). That's yet more pressure to get Mopria right - otherwise your Windows users can't print, or have to get IT to give them permission to print when they WFH.

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 30, 2025 19:48 UTC (Wed) by pizza (subscriber, #46) [Link]

> For a lot of people, the IPP path supports everything they could possibly want, though. Why would I care about the proprietary format, or the proprietary transport protocol, when PDF over IPP works just fine?

My point is that it often doesn't "work just fine", and in those situations, the fallback path is _worse_ than the old status quo.

I have printers on the shelf with critical-to-its-users features that IPP *as a specification* is _still_ incapable of representing "correctly" (On top of the features that are implemented "correctly" but are unusable because Apple refuses to fix bugs in iOS+MacOS)

Sure, IPP-everywhere is great for basic office documents and consumer photo printing. I'd even go so far to say that it represents a net win for 95% of the overall userbase.

But for that remaining 5%... the old status quo is becoming no longer _possible_, effectively pushing those users back to fully proprietary printing environments, because they can't afford to wait for the standards bodies to (1) figure out their use cases, (2) printer/print-servers to implement the new specs, and (3) standard print clients to reliably implement said specs, and (4) all parties to actually care about bug reports.

But none of that is my problem any more. [1]

[1] https://sourceforge.net/p/gimp-print/mailman/message/5916...

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 31, 2025 21:45 UTC (Thu) by ballombe (subscriber, #9523) [Link] (1 responses)

To give an example: I once bought a large copier/printer with automatic stapling capability. This feature was supported on Linux by the ppd file provided for CUPS. But this is more complex than just sending a PDF via IPP.

OpenPrinting need is declining (thanks, Mopria)

Posted Jul 31, 2025 22:37 UTC (Thu) by pizza (subscriber, #46) [Link]

> To give an example: I once bought a large copier/printer with automatic stapling capability. This feature was supported on Linux by the ppd file provided for CUPS. But this is more complex than just sending a PDF via IPP.

FWIW, stapling is one of the "finishing" options of IPP, formally standardized at least a decade ago. So yes, it really is as simple as specifying an additional property as part your IPP print job.

That said, I highly suspect there is no way to actually _specify_ that option when printing from standard operating system print clients/dialogs to a "driverless" IPP printer.. (I've seen plenty of stuff that uses IPP as the underlying transport but still uses a "driver" of some sort for the settings UI)