Remove print filters and printer driver support #4
Comments
|
@michaelrsweet thanks for the work on these sub-projects which will help fill the gap for the industries relying on this technology. I assume this thread is an open discussion like the previous and I hope my questions and thoughts are well received.
Although I think I understand why this wording is chosen, the shipping industry largely caters to PC owners that have the same (or perhaps similar) plugin-and-play expectations when printing, which is why this issue (as well as the previous discussions over at apple/cups#5271 are of great importance to companies affected by this change. Setting aside the industry's (Point of Sale, Shipping, Tickets, etc) perceived reluctance to adopt IPP, I find it important to still focus on the end-user frustration of "How do I print a label" (or "receipt" or "ticket") to begin ringing help desk lines as soon as these changes are adopted into an operating system. Some questions... I'll use LPrint as an example, but I assume any IPP-compatible printer application would be relevant instead...
Last, I'd love to hear a success story about an app that's already successfully leveraged LPrint in a user-friendly way (or a place such as a chat channel to talk with these people). I hope my questions are well received. |
|
@tresf Yes, please do continue to use this as an open discussion area. WRT label printers, there are certainly those that are targeted for SOHO users where the primary focus has been on smaller mailing/identification label uses where the vendor also provides a selection of labels - think Brother, DYMO, and the like. And then there are the "industrial" label printers where you buy labels in bulk from a convenient local/national supplier, often to print thousands of shipping labels per day. The expectations from the former group are very different from the latter, but both are best served by printers that implement IPP/IPP-USB and standard formats. WRT LPrint (and these responses apply equally to other Printer Applications):
WRT CUPS, yes it is going to lose the ability to host a raw queue. Tools like "ippeveprinter" could still be used to setup individual "raw" printers that CUPS could then print to, but honestly by the time we are ready to release CUPS 3.0 there shouldn't be any printers that don't have a corresponding printer application. It's not like we are charging forward on a whim, this has been in the works for years (I first started talking about it with printer vendors in 2010) and we want to make sure we have everything in place before we "throw the switch". |
I'd like to share my experience... Although this is largely true from 10,000 feet, it's not true in practice. For example, Amazon fulfillment is moving label printing from warehouses to homes. There's also a large use-case for label printers for non-shipping (e.g. inventory management). UPS worldship on Windows is another very popular SMB/home use application and it's perfectly normal to get a non-IPP capable printer for this purpose. As ISVs find creative ways to leverage CUPS to perform similar (e.g. UPS worldship-style) tasks, the hardware is slowly becoming commonplace on Mac, Linux and other CUPS environments. At least from my corner/soap box of tech -- SOHO (Small Office/Home Office) to SMB (Small/Medium Business) to completely integrated enterprise environments, the printing support is mostly analogous. With the speed and setup of cloud services, it's completely normal for an ISV to start off coding to ZPL but then add proper support for a wider range of hardware and the end-user rarely knows or cares about this, regardless of their business size.
Thanks, I'm hopeful this becomes true, this is great news.
Great, the existing CUPS IPP sockets seem to work well in a sandbox, but as you've stated, if the "driver" install binds to some form of LPrint wizard, this will already be done by the time the ISV need to talk to the printer.
Right, I think a source of concern would then be LPrint adoption at large (e.g. Apple). Thanks for sharing your feedback on all of this, it's greatly appreciated. |
|
@tresf FWIW, I'm well aware of the "work from home" warehousing. Existing SOHO label printers are, quite frankly, not up to the task. The mid-range industrial printers (Zebra, etc.) are OK, but usability is on par with the high-volume models and requires a fair amount of manual configuration and, of course, a driver/Printer Application... I've been working with one vendor on a new 4" medium volume (~5000 4x6 labels/day max) SOHO label printer with AirPrint/Mopria/IPP Everywhere/IPP-USB support. This printer works, out of the box, with Android, Chrome OS, iOS, Linux, macOS, and Windows 10 using IPP - no drivers or Printer Applications needed, all using IPP and Apple Raster, PWG Raster, PNG files, or PDF (yes, PDF!) |
|
An update on available Printer Applications: Most existing free software CUPS drivers are already available in Printer Applications. They are in the 5 Printer Applications listed below. You can get them all in the Snap Store: LPrint, the other 4 These are the Printer Applications (links to their source repositories):
Driver Listings on OpenPrinting have links to the Printer Applications now. If you are using a laser printer from Ricoh and OEM (Gestetner, InfoPrint, Infotec, Lanier, NRG, Ricoh, Savin) they are supported by the PostScript Printer Application (PostScript models/mode) and the GhostScript Printer Application (PDF and PCL models/modes). Ricoh is supplying me with support for the newest models regularly and I am updating the Printer Applications appropriately. The Printer Applications support the CUPS drivers with their full functionality, including back- and side channel functionality. For this the Printer Applications use the CUPS backends and not the PAPPL ones, especially also CUPS backends which come with the drivers. Note also that there are two errors in the initial posting of this issue:
|
|
As a mere user, is this important? I care solely whether |
|
@BEEDELLROKEJULIANLOCKHART this change is not about scanning, so no impact on iscan package. And regarding printing functionality, in case your device supports a driverless standard (Airprint/IPP Everywhere for network, or IPP-over-USB for USB) and its options suit you, you can switch to driverless and abandon the printer driver package. In case you have old device or driverless doesn't work for you, you will have to use a printer application - they are currently available as SNAPs. |
|
Is there a quick way to test this new functionality (e.g. a Linux distro that makes this pretty easy to setup and test without breaking a live machine)?
I thought raw was being removed too per apple/cups#5271. |
IMHO all distros don't break a live machine if you set this up, since CUPS supports all ways (printer driver, driverless and raw) for long time - although there is one tweak, which does not break your machine, but prevents you from testing temporary queue functionality - you just have to make sure to don't use the same queue name for your old permanent queue as the temporary has, otherwise CUPS will not create a new temporary destination (to protect your current configuration). as you can see, libcups strips or replace not-alphnum characters in mDNS entry and use it as queue name for temp queue. About being pretty easy to setup, it's subjective - IMHO driverless printer (which is a printer supporting AirPrint/IPP Everywhere/IPP-over-USB or any other driverless standard) can be setup pretty easily on all distros, just plug them/set them up on your local network and your good to go - at least from CUPS perspective, how your favorite application handles a temporary queue is a quite different story... As for non-driverless printer, you have to install a correct printer application from SNAP repository, configure it via its web interface/CLI and then CUPS sees it via mDNS. There is work in progress on implementing this via GNOME Control Center, so it might be easier in the future. As for distros where you can test - any distro with recent CUPS (in general approx 2.2.7 or 2.2.8 and up is good start (or an older if fixes are backported as I did in RHEL 8/CentOS Stream 8) - since there was an important fix regarding IPP Everywhere there, but the API is in place since 2.1 or 2.0) and snapd will do - differences can lie in whether you have to install and start Avahi and nss-mdns plugin, which are needed for mDNS support and .local hostname resolution. But from my experience Fedora and Ubuntu work for this.
driverless != raw Driverless means the printer driver functionality is substituted by IPP protocol (printer's options and settings are communicated via IPP instead of being taken from PPD file) - driverless queue is a queue which communicates with printer by IPP 2.0+ and has
|
|
@michaelrsweet ad removing print filters - do we expect applications doing document format conversion to a document format acceptable by a printer? Viewers and tools seem to pass a certain document format regardless of what the destination accepts (evince, firefox, libreoffice send PDFs, okular, xpdf send PostScript, lp just copies in the exact file from CLI), so IIUC printer will print garbage if the file is not converted to a printable format. F.e. my printer which works with IPP Everywhere (printer from 2010) shows only the following document formats: so without filtering I wouldn't be able to print text files (IIUC). |
|
@zdohnal in CUPS 3.x not all filters will get removed, only the ones which are classic printer drivers (like So desktop app developers should simply send PDF as they are already doing for a longer time. For Okular (or KDE/Qt ingeneral, please test) it is a bug to send PostScript. please report it, these apps have to send PDF, as all the other apps do. |
|
@zdonal We expect Printers to support standard file formats (Apple Raster, PWG Raster, JPEG, and PDF are specifically called out in the specs), and Clients (CUPS) to convert incoming print jobs to one of those standard formats. Today's applications already support PDF, and we have several choices (with licenses of varying openness) for converting PDF to Apple Raster and PWG Raster. The remaining issue is command-line printing of other formats - plain text, PNG, etc. - but as Till notes we have code for handling that already outside of the traditional CUPS filter chain. |
This is the part of this change that's the most concerning to me. A lot of printers as well as a lot of applications use the locally installed printers to start raw communication. It could be argued that the printer application should be written to handle this, but currently the respective drivers generally don't. For example, the drivers for Zebra and Epson printers have to be bypassed to talk to them raw, so I don't expect the replacement application to handle this any more gracefully (conversely, the Windows equivalents generally do). I've seen arguments that developers should just allow raw USB, serial, socket comms themselves, but when it comes to printing, this breaks user-space as users have to know a lot more about how a printer is attached. The use-case I'm still gravely concerned about, which I'm still unsure how to handle, is the Arguments to migrate to the applications that replace this support ignores the fact that in its current form, CUPS can use the PPD or bypass it. The application only seems to replace the PPD, not the ability to bypass it, which is tremendously important to supporting these industry printers moving forward. Even if these printers were to all get thrown into the garbage and new IPP capable hardware replacement were to hit the market, the missing raw commands would have to be added to the IPP specification, which just won't scale with device-spcific raw commands such as "eject cash drawer" or "download barcode font".
This sounds so much like a
Yes, sorry, you're right, apps like LPrint will fill this gap with existing functionality. I'm more concerned about testing the removal of raw queues. Perhaps this is more of a development question, but a quick way to get a system working with PPDs gone and raw queues gone so those relying on CUPS can better understand the impact this change will make. |
LPrint implements support for most of the label printers supported by the rastertolabel driver and it supports raw (ZPL/EPL/DYMO) printing. The key thing is that in the old driver-based architecture you can use the driver (PPD) or tell the printing system you are printing raw (preformatted) data. The same is true for IPP Everywhere, the difference is that you don't have a printer-specific driver, just a generic one for the standard formats required by IPP Everywhere. |
This is fantastic news, thanks.
This is the part I'd like to know more about. Many of the aforementioned environments don't really need the PPD today (depends whether or not they use the printer from other applications, really), so if there's still a way to add these printers without LPrint (or equivalent) and use them as raw queues (raw printing?), that would be nice to know (even while knowing most standard OS print operations would fail -- as they would today). There's also the gap of the receipt and line printers (e.g. ESC/POS, ESC/P), so knowing that users will have a path forward is critical. |
|
@tresf WRT a standard printing system providing standard interfaces to allow any application to print to any printer, there is no place for a printer that can't at least do basic raster printing - less than that and they are basically not printers. Case in point - those receipt/line printers can do raster printing as well as their basic text printing with hardcoded fonts/character sets (which would be your "raw" printing), so they'll work just fine. |
|
@michaelrsweet if the label or POS printers print with the same speed and quality in raster mode (do they?), getting everything rendered on the CUPS server, then one principally would not need raw printing, and one can even better predict what the printer will print. More a problem is to handle commands like opening a cash drawer (really strange that such a thing falls into the responsability of the printing stack). |
|
@tillkamppeter There are sometimes differences in quality and speed (particularly for old dot matrix printers), but they can absolutely provide a basic level of printing, in addition to "raw" printing when it makes sense to do so. WRT things like the cash drawer commands (really "pulse pin N"), there has been some discussion of adding an IPP operation for this which can then be discovered and used by a client. However, the push back on that has been on several fronts:
Personally, I feel that if you are going to write a POS application that runs on some (embedded/semi-embedded) Linux distro which interfaces with specific receipt printers, writing code that opens a USB serial or usblp character device to spit out some printer commands using the vendor's SDK is not a difficult task. You don't need (and shouldn't use) CUPS for that, and the lack of raw printing support is not an issue. |
Not even close.
There are many advantages to rendering content, the largest is support for international characters (rendering right to left languages like Arabic on a raw device is extremely difficult) but the two shouldn't be mutually exclusive, I don't understand this philosophy and the industry really hasn't treated the printers this way either.
The lack of raster printing is happening because of the removal of PPD, so this is a bit of cart-before-horse problem. I'm asking for a lifeline for when this removal occurs, not to argue the definition of printing or even the "should CUPS even be used for this purpose" fundamental question. On Windows, the drivers handle any passthru/raw commands. On CUPS today, this is generally a bit more of a manual workaround (e.g. shell commands or CUPS APIs), but I don't think it's fair to tell the industry they shouldn't be doing this.
POS can, will and should run on non-embedded platforms, so I'm not sure why this is even part of the discussion. Yes, there was a time that POS terminals were largely closed, proprietary locked down system, but as businesses need cloud services, this is becoming less and less true. Most POS rus on Windows today but it doesn't need to be this way. Being able to take advantage of a printer as a raster device AND a raw device in CUPS has coexisted just fine, but when the raster drivers are removed, it would be nice to keep these systems at least on life support using raw and not ask them to switch away from a CUPS system for these purposes.
I feel minimizing the impact doesn't really help those looking to keep things working. It's really not trivial for apps looking to communicate with many varying devices via USB, Socket and Serial to take over this communication. What's a bit more trivial is for these companies to drop support for CUPS version x.x in general for these purposes such as "Sorry, we no longer support ESC/POS on Mac or Linux". In regards to the SDKs, some are unavoidable such as Brazil's government-mandated, fiscally-aware Bematech models, but for the vast majority of printers, the SDK isn't needed. This is important for many use-cases, as often the SDK is only offered for Windows anyways. I don't want to get too off-topic about how these printers should be used but rather understand if there will be viable workaround to keep them working, even in a degraded fashion until a proper printer application is created. |
|
@tresf WRT print speed, my experience has been that raster printing on thermal printers is just as fast, if not faster, than the "high level" drawing commands for these devices. When it comes to impact printers the reverse is true.
WRT not mixing graphics and native text, the problem is simple: the PDF/PostScript imaging model allows for color/grayscale, transparency, rotation, scaling, etc. of text, making the cases where you could actually use native text support very limited. Plus you need to provide desktop fonts that correspond to printer fonts, and provide some hints as to what sizes are supported, etc. Classic Windows GDI printer drivers would use this method to support mixed output, but GDI rendering is much more limited than PDF/PostScript.
PPD files in CUPS serve two purposes: to describe the capabilities and commands needed for PostScript printers (the original Adobe purpose), and to describe the capabilities and filters needed for raster printers (the CUPS extension). Till also wrote the Foomatic wrapper around Ghostscript that creates a sort-of hybrid PPD containing PostScript commands (for Ghostscript) and Ghostscript options/settings that enabled printing via Ghostscript-based drivers, some of which support vector/text drawing (but not for ESC/P devices...) But none of this connects raw printing to PPDs or excludes raw printing because of the IPP Everywhere/raster requirements.
At no time have we ever said this. What we have said is that we will not support raw-only ("dumb", "proprietary", etc.) queues - we can't manage jobs or monitor printer state for raw queues, and applications cannot print to them without explicit support for the printer's PDL. By requiring basic printing support and allowing raw printing, you get the advantages of both without saddling CUPS with supporting arbitrary crappy raw printers.
Traditional POS systems are vertically integrated and largely use embedded/closed software. Cloud POS systems (Square, etc.) are less so, but they also discard things like cash drawers and use network or Bluetooth printers and not bare hardware POS printers.
I think you are completely missing the point. Raster driver support is being removed from CUPS, but they can still be used with Till's wrapper printer application. And of course CUPS 2.x source code will be available for a long time to come if you are really stuck in a world that cannot adapt to new technologies. |
|
Thanks for the pointer to Till's wrapper... So to take two use-cases, please correct me if any of these assumptions are wrong:
Some notes on comments above:
I can assure you, this is simply not true. Cloud apps leverage the raw stuff too. I'd rather not get into an argument here about it, but there are hundreds of cloud-first applications that I work with directly that leverage these types of printers and use the printer's raw language as well as some other 1, 2 products that do the same.
My questions may be mal-informed, but there's no mal-intent. I'm trying to determine if CUPS will continue working with these devices or not and even raw comms are enough for many users.
I'll try to not take this as a personal attack. The raw stuff isn't going away (and based on all of the talk about "raw" above, it sounds like this is understood). What I'm trying to figure out (and others will too, but possibly AFTER this change has occurred) is what things will look like when support has been removed. If tomorrow the printer manufacturers wrote their own printer applications to bridge the gap that would be a solution, but historically, the manufacturers' support for CUPS has been slow and lacking (when compared to Windows), so it's important to understand what will work and what will not and what new steps users will need to take. Although CUPS has a fundamental "no raw queues" philosophy, it doesn't mean people that are still looking to use it are unwilling to adapt to change. For example, I worked with a French printer company "Evolis" to get some raw commands working with their hardware and its important to know what is the path forward (if any) when we can't setup a raw queue for these.
"Support" is the operative word here. I'm only asking for a communication channel as is available in CUPS today (albeit deprecated) and Windows. |
In short (please correct if any of this is wrong):
I'll provide any feedback on this process to the appropriate projects. |
|
...? I don't know much about CUPS or anything, but without PPDs, no printer I've ever used will ever show levels of ink to CUPS. Not to mention I never get the options to "Print Self-Test Page" or "Clean Print Heads” (last option broken since my Mint 21 update). Not sure why PPDs should be removed, given the trade-off of losing ink-level monitoring. Edit: I just want my IPP/IPPS and ink-levels. shrug |
|
@michaelweghorn WRT PPD options, they are generally a subset of what IPP supports. For PostScript printers, really the only PPD options that aren't mapped are marketing features like watermarking that should be done on the client or in the application. For CUPS drivers, there are a lot of configuration settings for Gutenprint and the odd printer-specific option (like the bidirectional/unidirectional controls for dot matrix printers), but nothing prevents those from being exposed as IPP attributes with defaults and/or presets for ease of use. And all of those IPP attributes are exposed by the "new" (2012) API. WRT Printer Applications, while they can conceivably be PPD-based, that is entirely an implementation choice. The two printer applications I maintain (LPrint and hp-printer-app) don't use PPDs, and the planned "native" Gutenprint printer application likewise won't need them since all of the information is part of its XML printer database. As for "just working", there is a reason we've been working towards this for the last 10+ years. We are at the point where all of the common Linux printer drivers are ported to and/or wrapped in printer applications. |
|
@nahall Please read up on the last 5 Linux printing summits (links on the OpenPrinting web site) - there is plenty of information if you look. But basically if you have a printer purchased since 2010 then it is highly likely it will work without any printer-specific software. WRT that specific Kyocera printer, if it supports IPP then that job accounting id should be a standard IPP attribute ("job-accounting-id") used for (you guessed it) job accounting. If that isn't supported by the standard print dialogs on Linux, then I'd file a bug against GNOME and/or KDE to get it added (I really haven't checked this particular attribute - macOS has supported it for a long time now...) |
I fixed an AirPrint issue early January by grabbing a vendor driver and installing it, switching the printer to static. Furthermore, my MFP I use at my home continually stops working with AirPrint, leading me to do the same. This notion that new stuff "just works" isn't reality. Furthermore, (broken record, sorry) there are specialty printer features that just don't make sense in CUPS, and that certainly shoves those printers to somewhere else (in my experience, when software doesn't run on Linux, they go to Windows, unfortunately). |
Now we should report a bug/feature request against the CUPS backend of the Common Print Dialog Backends as the print dialogs are going to switch over to use CPDB for centralized CUPS support. @michaelrsweet could you tell which additional options, like "job-accounting-id" are needed, to have a complete list? Or whether one can obtain such a list from the |
|
Thank you, the links are helpful to better understand how it will all work together. |
|
@michaelrsweet @tillkamppeter Thanks for all the information and links. Sounds like it may be time to do some more testing at some point. If there are any options that are missing, should those be reported as issues to the corresponding printer applications?
Does this mean that applications and frameworks (like Gtk, Qt, LibreOffice) should not switch from PPD API to the "new" CUPS API, but instead switch to using CPDB and drop direct use of CUPS API altogether? |
|
If anything looks wrong for you, please report it, for example to the Printer Application where it occurs. We will tell you then whether the culprit is perhaps something lse, like PAPPL or libcupsfilters. Inside a Printer Application please check the web interface, especially the pages "Printing Defaults", "Media", and "Device Settings" for each printer set up. Due to the fact that the interface between print dialogs and CUPS is rather complex, CUPS is frequently changing, and GUI toolkit/application projects do not have much expertise, staff/volunteers to keep up with print dialogs I have introduced the CPDB project and now we are succeeding to deploy it. So we are recommending to guy folks to switch to CPDB and implement everything CUPS-printing-related in the CPDB CUPS backend. See also https://openprinting.github.io/achievements/#common-print-dialog-backends |
|
@michaelrsweet I'm disappointed to read that the raw queues are deprecated and will be removed in the next major CUPS version. My organization uses CUPS as a print queue for Zebra printers, where we send native ZPL code to the printer. We fill in ZPL commands that auto-generate barcodes and special commands to program RFID chips on the labels as they are printed out. As far as I'm aware, it's not possible to do this with a raster-to-ZPL converter. We manage sometimes 30 printers at a single location, and many PCs can print to the same printer at once, hence the need for a queue manager like CUPS for all this to work. It is infeasible for us to write Windows C code that will retry connecting to port 9100 until success, especially when you're fighting with 30 other PCs trying to do the same - the print order completely goes out the window. I'll also make the case that CUPS already provides an intuitive interface for managing all the printers, and if we were forced to drop CUPS just to print raw files directly and create our own queue-capable socket receiver, we would have to reinvent the whole printer-setup GUI as well. I'm asking to please reconsider keeping raw-queue support for special cases like ours and for others who require this driverless feature. |
|
@klynastor LPrint is an example of a printer application that supports "raw" printing of ZPL. Removing raw queues (that don't work with standard applications and require special handling throughout the printing system) does not prevent you from doing "raw" print jobs (sending printer-ready data from a special-purpose application). So whether you are printing through the CUPS lp/lpr commands or using LPrint, you will continue to be able to send ZPL jobs. |
|
Awesome; thank you for the insight. |
|
Lots of work to rewrite my postscript generation code for another printer because of failing filters, or stay with a deprecated cups, also deprecating other things with it's required dependencies. |
|
@MG- Old printers are supported by printer applications, see other projects in OpenPrinting Github group - only their direct support in CUPS is being removed. |
|
Hopefully this is the right place to ask this question. How CUPS 3.x is going to handle pre-filtering of jobs? Right now CUPS handles this by passing on "known" file formats to cups-filters like gstoraster. Not all applications are going to generate a PDF or supported raster format to print. There are still legacy applications out there that will output Postscript via lpr or other means (this was the "defacto" standard for *NIX printing for quite awhile). There is also a question of custom pre-filters. One use case that I have encountered is using GhostPCL to convert raw PCL5 output to PDF to print to a CUPS destination. This is easily done with a shell script and cups-filters, but it appears that is all "going away" with CUPS 3.0. One nice thing about CUPS+cups-filters has been its ability to just send anything to a printer queue and it handled the magic behind the scenes. Also, please don't underestimate the amount of legacy gear out in the field. Individuals and businesses use printers that are over 10 years old that don't support IPP Everywhere. Many folks are using CUPS as a bridge to make those printers IPP Everywhere/AirPrint compatible and are concerned about their workflows breaking (it appears that printer applications seem to fix this problem without even needing CUPS!). They may also be using CUPS as a bridge to allow legacy systems to print to modern printers as well. |
|
I have several comments: 2 - Regarding the comments above "Old printers are supported by printer applications, see other projects in OpenPrinting Github group - only their direct support in CUPS is being removed". I looked at the OpenPrinting group page. It is not at all obvious, where on thos pages these supposedly readily available printerapplications are that would be a substitute for CUPS. 3 - In my humble opinion this initiative reminds me of someone who can't stop picking at a loose thread on a sweater, until they discover that the whole thing has unraveled - in other words "if it ain't broke, break it. Then there will be something to fix." :) 4 - By all means, extend CUPS to support these new IPP/2.0 printers if you must, but leave the old stuff alone. |
|
@Dan-Essin To address your concerns:
|
To me, it sounds like cutting off branches of a tree for no reason. I don't understand the problem with "legacy crap". It's all USB. In the end, you can capture every byte. At least, if your OS provides access to the hardware at kernel level... What should remain is a massive summary of operational settings of printer models. How can the age matter? |
@MG- TL;DR: Printing isn't just USB, and (until the current IPP-based standards) was not standardized at all. Printing is really hard, with incredibly complex machines that feed media and deposit ink, toner, heat, etc. in order to put "dots on paper." The older the printer, the less standardized it is with other printers. Longer answer... It isn't all USB, and in fact network printing is now far more common than USB. Moreover, aside from standardizing the USB class interface for transferring print data (which if you look at the CUPS USB backend code you'll discover we have to maintain a "quirks" file to work around common USB implementation errors), every vendor has at least one custom printer language they use for that print data, thus the proliferation of print drivers that must be packaged for the architecture and OS you are using. And this printer driver architecture has its problems - PPDs being used for non-PostScript printers, non-standard options, an inefficient interface between driver, backend, and printer, and inconsistent handling of common things like canceling a job, checking supply levels, etc. Some legacy printers are little more than a USB port attached to the printer hardware, requiring precise timing and instructions over the USB from the computer connected to it. IPP and IPP-USB provide a common interface for network and USB printers. IPP Everywhere, AirPrint, Mopria, and Wi-Fi Direct print services standardize on IPP, IPP options, and a few common file formats (Apple/PWG Raster, JPEG, and PDF). Basically every home or office printer sold in the last 13 years supports these things, with many label and large format printers supporting IPP printing as well. All of these printers work without quirks and without custom printer driver software. Printer applications bridge the gap between the standard IPP interface and printer-specific languages, options, and interfaces. The "retrofit" printer application uses existing CUPS drivers, but other printer applications such as my LPrint and HP Printer Application provide an optimal bridge to existing label and legacy laser printers that are in wide use. All allow existing and future versions of CUPS to support these non-IPP printers in a standard way, and even continue supporting really old CUPS drivers that are only available in binary form for an unsupported OS or architecture (e.g. 32-bit x86 on 64-bit x86 or ARM, or an old version of Red Hat) since the printer application can run in a virtual machine container/emulator (yes, this is a real problem...) |
|
I realize I'm a bit late to the discussion. Could the PPD (etc) support be forked off into a CUPS plugin that the community could either maintain itself or something... In theory that would give folks who believe there is no other way somewhere to collaborate. |
|
@jcpunk This has happened over the last several years - libppd, pappl-retrofit, libcupsfilters, and ps-printer-app. We have been preparing for this change since I first started talking about it at the 2011 OpenPrinting Summit (12 years ago!) Believe it or not, the people involved in developing CUPS are vested in its long-term success and in supporting existing users, making any changes as painless as possible... |
|
Forgive me my uninformed standpoint here. I'm a user. I just want to print. I'm using CUPS with an old Brother USB printer to give it network capabilities. It can only do USB. It's a DCP-J125 in case that matters. The driver is a handful compiled x86 binaries.
I'm not sure if my printer can do that. All I know is that when I print a PDF the driver creates a lot of CPU load. It does that when printing anything though. Will I loose functionality if I upgrade? And if so, what do I need to do to keep operating my printer? I really tried following along, but there are just way too many printing details I don't know enough about. Some advice would be appreciated. |
No, you'll just need to use a printer application to host the driver when the time comes. (Assuming that your binary driver from Brother even works with the Linux distro you use by then...) |
|
This is shaping up to be another systemd situation, isn't it? "Removing" support for printer drivers by calling them printer applications is one thing, assuming that driverless printing actually works (to the full capabilities of the printer) another, but the idea of using snaps for it all is horrifying. A lot of what's in the "achievements" blog post is rather dystopian, really. |
|
Brother HL-L2310D series (USB only) stopped working too. |
|
@fallenguru Surely there will be distributions which will ship the printer applications as packages. |
|
@dptpirate This issue is not implemented in CUPS 2.x, so the reason why your printer does not work is different from this issue. |
Something must have changed in 2.x. It worked for the last 4 years (last successful use was last april), now it whines in the logs about "driverless" and "ippfind" failing to resolve DNS-SD, which I have explicitly disabled in the config files. Is there a new requirement for DNS-SD? How can I disable those "driverless" and "ippfind" things which I have no use for? |
|
@dptpirate please report it to your distribution via its bug trackers for further investigation. Its maintainers know how they set up printing stack in OS and what is required. |
|
@zdohnal Will do. Thanks. |
Why do we want to do this?
We already have a replacement for raw queues for shared printers (local/temporary queues managed by cupsd), and raw queues for special-use printers already largely bypass CUPS and can use existing commands or character device files to communicate with those printers.
As for printer drivers, those few printers that "need" them can migrate to standalone applications/services using the CUPS API to provide an IPP Everywhere-compatible Printer instance. PAPPL provides a convenient framework for easily creating these applications and porting existing CUPS raster drivers, and the following printer applications are already available or (in the case of Gutenprint) under development:
The text was updated successfully, but these errors were encountered: