Printing is declining
Printing is declining
Posted Jul 29, 2025 14:29 UTC (Tue) by fmyhr (subscriber, #14803)In reply to: Printing is declining by jengelh
Parent article: Help for OpenPrinting needed
Posted Jul 29, 2025 14:45 UTC (Tue)
by jorgegv (subscriber, #60484)
[Link] (18 responses)
Posted Jul 29, 2025 14:47 UTC (Tue)
by jorgegv (subscriber, #60484)
[Link] (4 responses)
Posted Jul 29, 2025 15:05 UTC (Tue)
by joib (subscriber, #8541)
[Link] (3 responses)
No personal experience though. Getting a Brother has been my plan for whenever I need a new printer, but my hand-me-down HP stubbornly refuses to die.
Posted Jul 29, 2025 16:09 UTC (Tue)
by paradoxmo (guest, #101515)
[Link]
I recently ran into this when I took a printer with me overseas and found I couldn’t buy the correct EU cartridges anymore in Asia. I ended up having to dremel the correct notch and pull the chip from the old cartridge to put it in the new one.
Posted Jul 29, 2025 17:59 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
That was a scare based on a Reddit post. A user had a problem with the printer and Brother's support asked to use the first-party cartridge. That's it.
I have just bought a new Brother printer for our office, and I can confirm that third-party cartridges work fine.
Posted Jul 29, 2025 18:05 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 29, 2025 19:05 UTC (Tue)
by WolfWings (subscriber, #56790)
[Link] (12 responses)
Posted Jul 29, 2025 21:08 UTC (Tue)
by jengelh (guest, #33263)
[Link] (11 responses)
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.
Posted Jul 30, 2025 6:20 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jul 30, 2025 8:33 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (9 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.
Posted Jul 30, 2025 11:28 UTC (Wed)
by pizza (subscriber, #46)
[Link] (8 responses)
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.
Posted Jul 30, 2025 13:42 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (7 responses)
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.
Posted Jul 30, 2025 17:38 UTC (Wed)
by pizza (subscriber, #46)
[Link] (6 responses)
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.
Posted Jul 30, 2025 17:53 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (5 responses)
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.
Posted Jul 30, 2025 18:16 UTC (Wed)
by pizza (subscriber, #46)
[Link] (4 responses)
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)
Posted Jul 30, 2025 18:30 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (3 responses)
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.
Posted Jul 30, 2025 19:48 UTC (Wed)
by pizza (subscriber, #46)
[Link]
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...
Posted Jul 31, 2025 21:45 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Jul 31, 2025 22:37 UTC (Thu)
by pizza (subscriber, #46)
[Link]
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)
Posted Jul 31, 2025 6:05 UTC (Thu)
by callegar (guest, #16148)
[Link] (2 responses)
At the office we have a Brother printer that is immediately usable by Linux systems, using the "driverless" printing, but I always got bad feelings about that printer, since the print quality was not that good, with thin lines typically too much faded out and documents that, while apparently reasonable in look, gave some "not fully rationalized" impression of having something wrong and requiring more effort to read.
One day, I happened to use it with a "generic" (PCL, I think) printer driver, that also happens to work with it. The difference in quality is immense. There is also a specific "traditional" driver from the printer that can be downloaded from the Brother site, but I have never succeeded in making it work with modern Cups. So, from that moment on, I always install the "generic" "traditional" driver.
I have been told that this is because with driverless printing the job gets rasterized before hand and that the rasterizer may not get sufficient information for doing it properly. Whenever for some reason the rasterization does not match the printed pixels perfectly (i.e. some scaling is involved) the quality is compromised.
I wonder if anyone more experienced than me in driverless knows if this is a general problem or just a bad implementation.
Posted Jul 31, 2025 11:34 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
It's most likely due to crappy client-side rasterization, assuming the same settings were requested in both cases.
That said, another anecdote -- About three years ago, I purchased a Brother HL-L2370DW. It supports driverless IPP, and JustWorked(tm)... usually. Sometimes, the printer couldn't be found, or print jobs would just... disappear. This happened especially often with my partner's Mac. Naturally, that made it *my* problem to resolve. This printer supports PCL6 via JetDirect, so as an experiment I added a remote JD queue to my existing (and very underpowered) CUPS print server, using Gutenprint to do the PCL wrangling and CUPS providing the driverless IPP frontend. Not only did that arrangement never so much as hiccup, it was consistently_faster_ -- both in time-to-first-page and overall throughput. The subjective print quality seemed effectively identical.
A couple of printer firmware (and MacOS) updates later, and driverless IPP to that Brother printer works considerably more reliably. It's _very_ nice when it works, but when it randomly doesn't... you're completely SoL. (Oh, I should mention that the printer and the CUPS server is connected via ethernet...)
(Also anecdotally, Brother printers are noticeably faster when using PCL as opposed to PostScript. And more reliable too, due to a couple of longstanding "quirks" in their PS emulation..)
Posted Jul 31, 2025 11:53 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Wanted to add something here -- Standards-compliant "IPP-Everywhere" requires that the printer accepts at least one of:
a) PWG-Raster, where the client pre-rasterizes each page and sends over a bitmap
Lower-end models only accept a raster format, which means the quality is entirely dependent upon the client. You'll need a higher-end printer for it to natively accept PDFs (or PCLm).
Printing is declining
Printing is declining
Printing is declining
Printing is declining
Printing is declining
Printing is declining
Printing is declining
Printing is declining
The least-software scenario is a print queue which forwards print jobs to another host without any conversion whatsoever.
Printing is declining
Wol
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).
OpenPrinting need is declining (thanks, Mopria)
OpenPrinting need is declining (thanks, Mopria)
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".
OpenPrinting need is declining (thanks, Mopria)
OpenPrinting need is declining (thanks, Mopria)
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.
OpenPrinting need is declining (thanks, Mopria)
OpenPrinting need is declining (thanks, Mopria)
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?
OpenPrinting need is declining (thanks, Mopria)
OpenPrinting need is declining (thanks, Mopria)
OpenPrinting need is declining (thanks, Mopria)
OpenPrinting need is declining (thanks, Mopria)
Printing is declining
Printing is declining
Printing is declining
b) JPEG, which is decompressed and processed (eg to produce halftones and/or color channel separation as needed)
c) PDF, which the printer will then process/rasterize as appropriate
Proprietary IPP variants have their own PDLs. Apple's AirPrint has URF ("Universal Raster Format"), and Mopria has "PCLm", which can be thought of as a variant of PDF that is more amenable to streaming)