Printing is declining
Printing is declining
Posted Jul 31, 2025 6:05 UTC (Thu) by callegar (guest, #16148)In reply to: Printing is declining by fmyhr
Parent article: Help for OpenPrinting needed
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
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)