search

OpenPrinting / cups-sharing

Sharing server for CUPS 3.0
https://openprinting.github.io/cups/cups3.html
Apache License 2.0
5 stars 4 forks source link

Remove print filters and printer driver support #4

Open michaelrsweet opened 3 years ago

michaelrsweet commented 3 years ago

Note: The goal of this issue is to have a place to discuss the eventual removal of printer driver support and support for raw queues in OpenPrinting CUPS v3.0. The original Apple CUPS bug report has some additional history, and what exists here is an updated summary of that historical discussion.

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:

tresf commented 3 years ago

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

"vertical market printers"

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 https://github.com/apple/cups/issues/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.

michaelrsweet commented 3 years ago

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

tresf commented 3 years ago

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.

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.

I'd expect it to be installed by default or offered to be installed when you connect/discover one of the printers that LPrint supports.

Thanks, I'm hopeful this becomes true, this is great news.

LPrint provides a standard IPP service (TCP/IP socket)

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.

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.

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.

michaelrsweet commented 3 years ago

@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!)

tillkamppeter commented 3 years ago

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:

RokeJulianLockhart commented 2 years ago

As a mere user, is this important? I care solely whether iscan-firmware, epson-inkjet-printer-escpr, and epson-inkjet-printer-escpr2 shall continue to operate.

zdohnal commented 2 years ago

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

tresf commented 2 years ago

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)?

you can switch to driverless and abandon the printer driver package.

I thought raw was being removed too per https://github.com/apple/cups/issues/5271.

zdohnal commented 2 years ago

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)?

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). The temporary queue name is created from:

$ avahi-browse -avrt
...
= enp0s25 IPv4 HP LaserJet M1536dnf MFP (42307C)             _ipp._tcp            local
...
$ lpstat -e
HP_LaserJet_M1536dnf_MFP_42307C

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.

you can switch to driverless and abandon the printer driver package.

I thought raw was being removed too per apple/cups#5271.

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 IPP Everywhere model or it is a temporary queue. Regarding raw, we should make a difference between raw queues and raw printing:

zdohnal commented 2 years ago

@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:

document-format-supported (1setOf mimeMediaType) = image/urf,application/pdf,application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL

so without filtering I wouldn't be able to print text files (IIUC).

tillkamppeter commented 2 years ago

@zdohnal in CUPS 3.x not all filters will get removed, only the ones which are classic printer drivers (like rastertohp) or only serve for obsolete data formats (like pstops) will go away. CUPS 3.x will still have filters which turn typical input formats (PDF as it is sent by nearly every desktop application, Apple Raster to allow iOS devices print on a shared CUPS printer, PWG Raster, and perhaps some others) into the 4 output formats needed by driverless iPP printers, PDF, Apple Raster, PWG Raster, and PCLm.

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.

michaelrsweet commented 2 years ago

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

tresf commented 2 years ago

driverless != raw Raw queue is a queue installed with raw model, so CUPS is not able to get a printer information and options either from IPP or printer driver, so you don't see any options via lpoptions and no filtering happens during printing, regardless of input document format. For raw queues CUPS counts on the application knows what options printer has and sends a print-ready file to cupsd itself, so cupsd here acts only as a transfer layer. This feature is going away in CUPS 3.0.

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 lpr -o raw replacement. Users will continue to buy these Epson and Zebra (Citizen, Boca, Honeywell, Star, etc) printers, but they'll be forced to move to a Windows platform if they can't use it with applications that send raw commands. Although it could be argued that it's not CUPS' (or more generically the printing subsystem) responsibility to provide this communication channel, the industry can't recover from this without a path forward. The push to IPP Everywhere has a lot of benefits, but the removal of a raw communication channel makes CUPS-based platforms dead in these industries the day the change goes live.

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

Raw printing means sending a file, which printer supports, to a queue, which is driverless or with a printer driver, so no filters are applied - options can be applied depending on which communication protocol you use with printer (f.e. printer supports Postscript and communicates via IPP, so if you send PostScript file via IPP with options, they are applied. However if you do the same with socket or usb backends, the options are not applied, because they don't send options to the printer and count on filters or application to apply them). However if you send a different file format to this queue, it is converted to a document format acceptable by the printer. This feature is not going away, actually IIUC this will be the only way of printing after print filters are gone from CUPS (moved to printer applications for printers which need them)

This sounds so much like a Raw queue that I'm not even sure what the functional difference is. Are you stating that Raw printing should fulfill the (my own) above use-case?

IMHO all distros don't break a live machine if you set this up, since CUPS supports all ways (printer driver, driverless and raw)

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.

michaelrsweet commented 2 years ago

@tresf

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

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.

tresf commented 2 years ago

LPrint implements support for most of the label printers supported by the rastertolabel driver and it supports raw (ZPL/EPL/DYMO) printing.

This is fantastic news, thanks.

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

michaelrsweet commented 2 years ago

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

tillkamppeter commented 2 years ago

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

michaelrsweet commented 2 years ago

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

tresf commented 2 years ago

@michaelrsweet if the label or POS printers print with the same speed and quality in raster mode (do they?)

Not even close.

getting everything rendered on the CUPS server

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.

there is no place for a printer that can't at least do basic raster printing

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.

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.

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.

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.

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.

michaelrsweet commented 2 years ago

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

There are many advantages to rendering content, the largest is support for international characters https://github.com/qzind/tray/pull/339#issuecomment-404030141 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.

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.

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.

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.

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.

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.

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.

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.

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

tresf commented 2 years ago

Thanks for the pointer to Till's wrapper...

So to take two use-cases, please correct me if any of these assumptions are wrong:

  1. Sending ZPL to a Zebra printer (moving forward will use LPrint)
    • :white_check_mark: Support for 2D/raster content will work; sending raw ZPL should also work.
  2. Sending ESC/POS to a receipt printer (moving forward will use ghostscript-printer-app
    • :question: This is partially what the above conversation is about, because the PPD files are maintained by a 3rd party... I seems like ghostscript-printer-app is being proposed... Since ghostscript-printer-app is being distributed as a snap, I assume it can't locate the old PPD files on the machine, is there a migration procedure for the old raster apps that shipped by the manufacturers? If so, will the old PPD location stick around for a while so that the installers can continue to place them there for IT technicians to find (and then copy to the wrapper)? Or instead will technicians be expected to extract these on an old CUPS 2.x system and copy the PPD files to the wrapper?

Some notes on comments above:

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

At no time have we ever said this. [...] By requiring basic printing support and allowing raw printing, you get the advantages of both without saddling CUPS with supporting arbitrary crappy raw printers.

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.

if you are really stuck in a world that cannot adapt to new technologies.

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.

supporting arbitrary crappy raw printers.

"Support" is the operative word here. I'm only asking for a communication channel as is available in CUPS today (albeit deprecated) and Windows.

tresf commented 2 years ago

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)?

In short (please correct if any of this is wrong):

  1. Use CUPS 2.2.8+, e.g:
    • MacOS 13.0 Beta 6 ships with 2.3.4
    • Ubuntu 22.04 ships with 2.4.1
  2. Move any affected printers to a printer application

I'll provide any feedback on this process to the appropriate projects.

OdinVex commented 2 years ago

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

tillkamppeter commented 2 years ago

@OdinVex, if you simply create a CUPS queue without PPD, using the current CUPS you will for sure loose functionality. If we switch to a CUPS not accepting classic drivers and PPD files any more, Printer Applications replace the drivers and overtake all their functionality. Supply level readout for those printers where it worked with CUPS is planned for all Printer Applications. One sample Printer Application already doing it is @michaelrsweet 's hp-printer-app.

Could you also attach your printer's PPD file(s) here (from /etc/cups/ppd, you need to rename them adding .txt to the end of the name so that GitHub accepts them). So we can see which attributes related to ink level readout and printer maintenance operations are defined in the PPD, which helps us to improve our Printer Applications.

OdinVex commented 2 years ago

@tillkamppeter, So in other words, PPDs should definitely not be deprecated or disabled until such functionality is implemented and operable. Is everything being branded under HP's name these days (hplip, hp-printer-app, ..)?

I've attached the PPD used. Before my upgrade to Linux Mint 21, 'Clean Print Heads' did work. I rarely ever print, so I used it before every print-job (once every six months or longer). All three options, 'Print Test Page', 'Print Self-Test Page', and 'Clean Print Heads' worked before the upgrade. Now, I've only gotten 'Print Test Page' to work. An old bug with this printer, it only supports IPP 2.0, I've always been forced to add 'version=2.0' to the URI. Meanwhile, typing this, it's all decided not to work at all. I hate Linux printing, and I've no clue why someone decided the world needed to use servers installed just to print. Sigh.

Edit: I've just read that Printer Applications page. Snap? Really? Ugh. I've been on a *buntu-derivative for far too long, time to leave the turd behind and go Arch & AUR. AppImage/Flatpak/Snap, horrible stuff. I can only guess how printers through Linux will run in the future. Probably a VM of a sandbox VMing a VM of a sandbox. Never mind, thanks for the post anyway. Genuinely, good luck.

tillkamppeter commented 2 years ago

@OdinVex Note that "deprecation" does not mean removal. "deprecation" means that the concept is planned to be discontinued in a later version, for example when a successor for it gets available. Also development has often stopped on deprecated features, only bugs being fixed in them.

First, your PPD is part of a manufacturer-supplied, proprietary driver. Manufacturers have to turn such drivers into Printer Applications to assure that they still work with CUPS 3.x.

Your PPD does not contain any information needed for a client to know how to poll supply levels or how to do maintenance tasks. How do you do this? which programs are you using for these tasks? The reason for such tasks ceasing to work is not the PPD or not using it any more (I assume you still use it. Curren CUPS still supports PPD files).

Your printer supports IPP 2.0, so it supports also driverless operation, not needing the proprietary driver and the PPD file at all.

Printer Applications are not necessarily distributed in Snaps. They are free software projects. Distros can package them as RPM, DEB, AUR, or whatever. OpenPrinting as upstream organization does distribution-independent packaging, currently Snaps, but more suitable formats to come, especially OCI containers. As Printer Applications are system daemons, Flatpak and AppImage are not suitable for packaging them. Distribution-independent packaging is important for manufacturers to make their drivers easily available, without needing to package and test on 10, 20, or more distributions. Also containers, like Snap or OCI are not VMs. The containerized app runs on the same kernel as the host system.

OdinVex commented 2 years ago

@tillkamppeter, I am aware that deprecation doesn't mean removal, developer myself. It's just that this “Printer Applications” bit seems a re-invention of a wheel, overly complex for no justifiable reason.

As for the PPD, it worked before upgrading to Mint 21 (received an update to CUPS as well, may have been Mint, may have been Ubuntu). I also never used the proprietary components of the driver, just the PPD extracted from their archive.

Oddly enough, I can query color using the same “Printers” (system-config-printer=1.5.16) software I always have. It only shows color information if I use the PPD. Otherwise, I'll get “Marker levels are not reported for this printer”. Ubuntu(?) is using cups=2.4.1op1-1ubuntu4.1 on Jammy, a bit old.

The printer can mostly work without the PPD, but 'Marker Levels' will fail and 'Print Self-Test Page' and 'Clean Print Head' won't even exist as options to query.

I was making a generalization about AppImage/Containers/Flatpak/Snap/VMs stuff altogether being just blegh, pointing out their separation from integration with the system. I know they're not VMs...I was reducing the point of separation to show an extreme to point out how bad they are. They need to die off, as they're nothing but a reinvention of the same wheels (brokenly) to wrongly solve the same problems they create or trade off on. “It solves DLL-hell” is wrong, “easier to distribute” can be done with things like AUR (rolling) and DEB (pre-compiled “stable” (aka ancient)) systems, “it increases security” maybe, but almost all these are useless for interacting with because of all that sandboxing/separation from the system. They cause more headache than they solve. Can't even use system themes with their Gnome crap (great, I've made myself sad being reminded of client-side-decorations...)

Anyway...tldr, PPD is necessary for standard function, for whatever reason. OOBE is lacking. Tried all 'recommended' “drivers” (useless, support far fewer options than the PPD, colors even go wrong, 'Marker Levels' will fail “not reported” and 'Print Self-Test Page' and 'Clean Print Head' won't even exist).

Edit: /me uninstalls printer to start fresh, installs, “Stopped - The printer configuration is incorrect or the printer no longer exists.”, laughs in Linux-Printing-Bites-Padded-Cell.*

gtwilliams commented 2 years ago

I got here because I saw this in my Fedora journal:

Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups-sharing/issues/4

What does this mean to me? What should I be doing?

zdohnal commented 2 years ago

Hi @gtwilliams ,

it means one or more printer you have installed are using classic drivers which support in CUPS will be removed in the future. What you should be doing depends on what printer do you have.

If you have 10 years old printer or newer, the device probably supports AirPrint or other driverless standard which can make your printer work without classic driver - there are several means for finding out.

In case none of those methods confirms that your device has a support for driverless standards, then it needs a printer application as a man in the middle to work with CUPS in the future. Printer applications are currently available as SNAPs and if your device was supported by a printer driver package in Fedora, then some of the already implemented printer applications will provide support for it.

I've written a detailed email to Fedora devel mailing list about how to test, here is the testing part.

adb336 commented 2 years ago

@michaelrsweet: which use cases have you collected in order to decide to drop raw support? Mine is: a printer not connected directly but instead advertised in LAN by its IP-address. The windows clients (server/desktop/laptop) use the their local Windows drivers and communicate directly with the printer (in my Case HP AIO8600). One Linux server (opensuse) uses the printer via CUPS and HPLIP ppd files. This server is advertising the printer so other Linux server (Raspbian, Ubuntu, Fedora and opensuse) can use it through the CUPS-browse mechanism.

Would this be possible with 3.x?

Isn't it an idea to collect the use cases first and then see if the future design can support those?

And if not: what are your suggestions for use cases no longer supported? Might be useful to create a wiki around changes to be addressed by all of us being affected by the change.

Kind regards,

Alex

michaelrsweet commented 2 years ago

@adb336 Your HP printer remains supported via a printer application that already exists today. You can route jobs through the printer application or through your Linux server.

The only thing this bug is tracking is the removal of printer drivers and driver support for the CUPS core services - that functionality is moving to printer applications, all of which (at the moment) use my PAPPL library to provide a consistent interface/wrapper for those drivers to make them into printer applications. I'm not going to repeat all of the advantages of this approach, just trust me that we've been working towards this for the last 12 years and are not rushing things or ignoring common use cases - we want something that can be supported over the long term.

OdinVex commented 1 year ago

So in short, for all of this...direction that CUPS is taking, someone will need to fork CUPS to provide exclusive support for any printer that needs a PPD to access all of its features or requires something other than 'text-like' printing support. So pretty much all printers. Or just stop using printers altogether. Shifting all PPD-printers back to the manufacturer is just going to take consumer-printing back 20 years. Who are you working for? Who are you sabotaging CUPS for? Seriously. -_- I'm not buying a new printer just to support useless driverless sandboxed printing that can't communicate at all with a printer, just because all printers are fine with PPD and you want to remove that. Makes no sense. Wish you well, but I'm just going to Raspberry Pi my printer and keep it on an older version of CUPS with PPD. No longer receiving notices for this, CUPS's usefulness is done.

tillkamppeter commented 1 year ago

@OdinVex nobody needs to fork CUPS for that. If the printer needs only a PPD to know about all its options and settings, we have a PostScript printer and this is supported by the PostScript Printer Application mentioned here. If the needed PPD is not alredy included with the PostScript Printer Application, you can use the "Add PPD file" facility in the web admin interface of the PostScript Printer Application and upload your printer's PPD file into it.

If you have a printer with an arbitrary classic CUPS driver, installed via any type of package to the locations where CUPS 2.x expects the printer drivers and you have CUPS 3.x installed, you only need to install the Legacy Printer Application which is a part of pappl-retrofit. This Printer Application looks for classic CUPS drivers where CUPS 2.x expects them and makes them available as Printer Application, emulation of a driverless IPP printer. So CUPS 3.x can use them and you do not need CUPS 2.x any more.

So everything is taken care of ...

michaelrsweet commented 1 year ago

@OdinVex OK, I think you seriously misunderstand where we have been going for the last 13 years.

First, ALL current printers and drivers are already supported by one or more "Printer Applications". Every printer that works today with a CUPS printer driver also works today with a printer application. And those printer applications can run on a desktop computer, Raspberry Pi, etc. to support printing from all of the devices on your network.

Second, 20 years ago most printers used a vendor-specific protocol and/or language/file format for printing. 13 years ago we started down a path of using standard, common protocols and languages/file formats, with the printer manufacturers participating with the OS/software developers to define those standards - "business as usual" no longer worked, so now we get to reap the benefits.

Finally, today most new printers support IPP, PWG Raster, JPEG, and often PDF out of the box. These printers need no special driver - they work with a single generic "driver" built into CUPS. That same driver works with the previously mentioned printer applications as well, so you can continue using the same printers and drivers, just with things moved around (behind the scenes) so that everything works better and more reliably...

OdinVex commented 1 year ago

Apparently @ mentions still notify. *sigh*

@OdinVex nobody needs to fork CUPS for that. If the printer needs only a PPD to know about all its options and settings, we have a PostScript printer and this is supported by the PostScript Printer Application mentioned here. If the needed PPD is not alredy included with the PostScript Printer Application, you can use the "Add PPD file" facility in the web admin interface of the PostScript Printer Application and upload your printer's PPD file into it.

Installing additional software, no different than simply forking CUPS. At least with just a forked/archived version of CUPS I'd have all-in-one.

So everything is taken care of ...

Re-invented wheel needlessly.

@OdinVex OK, I think you seriously misunderstand where we have been going for the last 13 years.

Printers are all unique, they need their own descriptions of functionality (PPD). CUPS currently supports it all.

First, ALL current printers and drivers are already supported by one or more "Printer Applications". The concept of “printer applications” can blow itself. There are printers, their drivers, and a means of communication (direct such as USB/LPT, network such as IPP). Nothing else needs to exist.

Second, 20 years ago most printers used a vendor-specific protocol and/or language/file format for printing. I was there. IPP in 1999, for example.

13 years ago we started down a path of using standard, common protocols and languages/file formats, with the printer manufacturers participating with the OS/software developers to define those standards - "business as usual" no longer worked, so now we get to reap the benefits.

IPP 1.0 alone was enough. The only thing that should've been implemented was a means of securing connections.

Finally, today most new printers support IPP, PWG Raster, JPEG, and often PDF out of the box. These printers need no special driver - they work with a single generic "driver" built into CUPS. I know about IPP Everywhere. It's a standard that should never have been, as it detracted away from printers simply being printers to now being processors.

That same driver works with the previously mentioned printer applications as well, so you can continue using the same printers and drivers, just with things moved around (behind the scenes) so that everything works better and more reliably...

That's the part that is re-invented and just overcomplicating things.

While I appreciate your attempts to...do whatever this is, there is no need to notify or @ mention me, none of this will change my mind about any of this Micros**t-like 'upgrade' to printing. The essential nature of printing is a printer, a direct means of communication (without the entire concept of server crap, that's the only concession I tolerated from CUPS), and a way of describing all features of the printer (PPD) for management and printing. Driverless is a lie because we the user can't control the interpretation of features. We're at the mercy of manufacturers. That never goes well.

Edit: Printers should only do the physical, they shouldn't think. This'll only lead to everything ending up behind software-controlled paywalls/corp-control. We don't have control except to unplug. No alternatives. This isn't tin-foil hat paranoia, it's reasonable suspicion with everything moving to subscription leechware. You can argue that this could only happen to new printers, but that's just it. CUPS is working older printers that need those PPDs. Shouldn't remove support. “But the PPA...” unnecessary and possibly unsupported in some environments. If older printers and CUPS setups are the only way to maintain user-control in this possibility, eh, I'll fork/archive (personal use..). Because of user/environment-support.

michaelrsweet commented 1 year ago

@OdinVex IPP/1.0 had security - authentication and TLS - same as the later versions. I know because I was there in the IETF IPP workgroup and later (and ongoing today) in the PWG's IPP workgroup. At the same time I was writing CUPS from scratch, and I chose to use PPD at the time because the printers of the day did not provide the information needed, but I knew back in 1997 that PPDs were a short-term solution and never expected them to last as long as they have, which is why I and a lot of other people worked for years to define standards and implement them so we aren't dependent on printer/OS-specific driver software.

WRT "interpretation of features", that is bullshit. Whether you use IPP+standard file formats or some vendor PoS driver and printer language, you are always "at the mercy of printer manufacturers" because they make the printers and choose the features and capabilities of each printer. At least with a standard protocol and file formats you can use that printer from any OS you want - with drivers you were at the mercy of the printer manufacturer to provide software or documentation for somebody to write a driver. Having spent most of my professional career writing printing software, I can tell you which way is the most rewarding and least frustrating!

OdinVex commented 1 year ago

... had security...

I meant it shouldn't have any at all, it should be up to the OS whether to share/auth. Printers should be as dumb as possible. Same for TVs if the firmware+software can't be user-controlled.

I I I

I don't care what you did or do. I don't care if you care or not, that I was trying to warn that CUPS PPD-support is being removed. Edit: Not that I'm ungrateful for anything you have done. I meant that I didn't care about any attempted credentials regarding this current move of CUPS to remove PPD. Strictly meant. For everything else, I'm actually quite grateful, and I thank you for having helped with (if you indeed did all of that other stuff).

... that is bullshit

No, it isn't. Anyone can edit a PPD to add/remove features (within the scope of the hardware). I've fixed several printer issues over the years relating to manufacturers not releasing a proper PPD, even provide user-trusted/supplied/compiled software for niche features if necessary.

... most rewarding and least frustrating.

A deal with evil, quite possibly. In any case, I don't care. As I said, I'll fork/archive and be done with this. You want to remove PPD support, go ahead, it's not my project, I merely tried warning you. You won't convince me of anything, just as I'm sure I can't convince you (and quite frankly, this looks like a sneaky subterfuge of open-source software to enslave users to manufacturers or is just an accident waiting for that to happen.) Ignoring entire Repo to stop @ mention notifications now.

OdinVex commented 1 year ago

Re-edited content above, left out a paragraph multitasking.

michaelweghorn commented 1 year ago

Thanks for all the work on improving printing!

I have been loosely following this, but some things are not really clear to me yet, in particularly from the point of view of applications/frameworks currently using the PPD API for providing printer-specific options in print dialogs:

My understanding so far (please correct me if I'm wrong):

Do printer applications bridge that gap now by mapping all arbitrary PPD options to IPP attributes and making them work with the driverless CUPS? In other words, will e.g. the example from https://github.com/apple/cups/issues/4969 (s. more details in the CUPS mailing list thread mentioned above) now "just work" when the printer has been set up with a printer application that uses that PPD?

If so: What is a proper way for applications and frameworks currently still using the PPD API to move forward? If all use cases are supported by the Job Ticket API with the proper setup including printer applications etc., it sounds like applications/frameworks should support that. At the same time, how to keep supporting the "old" PPD-based workflow until everything has been switched over (e.g. CUPS 3 has replaced CUPS 2 on all Linux distributions)? Should applications/frameworks support both ways for now, and then decide at run-time which one to use? (e.g. do a runtime check which CUPS version is used? Is there CUPS API for doing so?)

michaelrsweet commented 1 year ago

@michaelweghorn Some of the current printer applications actually use PPDs and handle the mapping to/from IPP attributes and values, much like CUPS has done since v1.0. I'm not sure how well the mapping from job-password to the various PIN printing options is working (@tillkamppeter might be able to say more) but the expectation is that the printer application will handle such things so applications won't need to know about such implementation details.

WRT application development, there is honestly no reason to support PPD-based UI in 2023 - those APIs have been deprecated since CUPS 1.4 (August 2009), with a high-level replacement (the "cupsDest" APIs) first introduced in CUPS 1.6 (July 2012) which provides an IPP-centric view of options and values with support for querying the loaded media, among other things.

michaelweghorn commented 1 year ago

@michaelrsweet Thanks for the clarification.

... but the expectation is that the printer application will handle such things so applications won't need to know about such implementation details.

That sounds great in theory, but as long as that is not the case in practice, I would personally see that as something to at least consider for application development. IIUC, while it should work in theory, there are cases where switching from PPD API to an IPP-centric view would currently result in reduced functionality in practice if relevant PPD options happen to be among those that are (currently) not mapped (properly). In fact, that is the reason why Qt 5 still used PPD API when implementing support for printer-specific options in 2017/2018 even though the API was already long deprecated then. (Qt 5 was the context/trigger for the above-mentioned discussion referenced in https://github.com/apple/cups/issues/4969 - starting at https://lists.cups.org/pipermail/cups/2017-January/056491.html .)

I don't claim to have the ultimate answer on whether or not the fact that "some" (potentially unknown amount of) PPD options might no longer work is reason enough to keep using deprecated API or not, and I'm certainly not in a position to be able to judge that best. But from my perspective, this is at least still a situation where I personally wouldn't feel confident yet to just drop that without keeping in mind there might be use cases that break - in particular if it's not clear whether and how those use cases will be addressed/fixed in a different component in the printing stack soon.

michaelrsweet commented 1 year ago

@michaelweghorn WRT support for the job-password option ("PIN printing" for common office multi-function printers/copiers), they represent a tiny fraction of installed printers (maybe 1 in a million?) and even the PPD-provided options are poorly supported/implemented. Some printers have a single option with a handful of canned choices ("1111", "2222", etc.) while others expose separate options for each digit (!). And honestly I don't think the reason Qt still uses PPDs it is only for PIN printing - Gutenprint has long abused PPD options and it supports much more common printers and use cases - the simplified PPDs do perfectly well and are mapped well to/from IPP, but so-called "expert" used claim they can't function without access to everything knob Gutenprint has to offer (which is quite frankly bullshit - they tweak things until they like them and then leave the settings alone, which is exactly what the printer application provides...)

Anyways, PPD support is going away and application developers will need to adapt. Updating ps-printer-app to support job-password is feasible, and looking through the current set of PPD files it should be possible to map job-password and job-release-action (new) to the corresponding PPD options/choices.

michaelweghorn commented 1 year ago

@michaelrsweet WRT Qt 5, I was somewhat involved back then. (A contractor implemented support for printer-specific options in Qt 5, after that had been dropped because it had been broken in Qt 4 days). My comment that the use of the PPD API was chosen was not referring to PIN printing alone, but more generally to PPD options that are/were not mapped to any equivalent available via the Job Ticket API.

A question to understand this better: What PPD options will not be working "out of the box" any more when switching from PPD API to Job Ticket API?

  1. a known set of PPD options (like PIN printing in the above case)
  2. all PPD options that are not explicitly mapped (but can potentially be made to work, if there is an IPP attribute equivalent and support is implemented explicitly in printer applications)
  3. something different

While I completely agree that the situation with PPDs defining arbitrary keywords is unfortunate and I'm very happy about the general direction of moving away from that, my impression so far was that 2) rather than 1) is the answer to the above question. In which case my understanding would be that it's not really known what features might break, given that there is - IIUC - an unknown amount of (old) printers and PPDs with custom options "out in the wild".

The mailing list thread mentioned earlier has more details, but just to explain a bit more of the background for my (and also our contractor's) reasoning back then: I did a quick test with a (then) quite recent device and ran into some PPD options that weren't working out of the box without using the PPD API. You instantly addressed three of them, the other one was considered in the realm of foomatic and at least the corresponding ticket against foomatic-filters is still open today. I would have loved migrating away from PPDs completely and just use IPP for querying the features directly from the device in the first place, but unfortunately the corresponding IPP attributes were not supported by the device. (And unfortunately, customer support from the manufacturer of the affected device told us that using that PPD was the only way to make it work...) Given that Job Ticket API wasn't even working to support all features on that one (rather recent) device I explicitly tested and my understanding was that there would be an unknown amount of other devices that might be affected similarly (with whatever non-standard PPD options they might be using for whatever functionality), using the PPD API for then seemed like the only option to keep all options working for existing printers at that point.

https://bugreports.qt.io/browse/QTBUG-56545 has a discussion on why Qt hasn't yet migrated away from PPD API. I've commented there with the (limited) understanding I had at that time, which is basically what I wrote here as well. I believe that your input there would certainly be appreciated. ( I also left a comment at https://github.com/apple/cups/issues/5271#issuecomment-623312012 inviting input back then.)

Is my understanding correct in general that with printer applications, there's still an explicit set of PPD attributes that is mapped to IPP (i.e. answer 2 from above), and if something is missing, it would have to be implemented in the printer application in order not to lose the functionality provided by those PPD options when switching applications from using the PPD API to the Job Ticket API? So is it essentially that mapping has moved from CUPS (where it was in CUPS 2.x) to printer applications, but the mechanism of mapping is still similar?

Again, I'm not suggesting that a "Yes" to that answer necessarily means that applications shouldn't switch (and as you say, they will have to do that at some point in time anyway). And I'm all for fixing things at the right place (presumably the printer application in most cases?).

But to be honest, it's still a bit unclear to me to what extent things will "just work" and where there will be issues when switching. And if there are issues, how fast users can expect to see their use case working again. For example, I didn't even find any packages for the printer applications mentioned at the top comment here in the Debian testing repository yet, so they won't get them by the default mechanism of their distro. So if users will be dependent on a change in such a printer application for things to work again, wouldn't that still be problematic in practice and there's realistic potential for users complaining to application developers that they broke things (as they switched away from using PPD API)?

nahall commented 1 year ago

Yes, it seems like it would be useful to have some examples of how current printers would be done with CUPS 3. If I'm understanding correctly, it seems like the goal is to separate CUPS current features into a more defined CUPS role along with these "printer applications" that combined would cover CUPS 2 current functionality. And then if someone just has basic printer needs they may not need any printer application since IPP works fine for that, right?

So that may cover 90+% of printer use cases but I'm just unclear on how those other printer use cases will be handled in practice, so by the time CUPS 3 is ready it would be good to have examples of how to use these printer applications with CUPS 3 to access some of these special printer features.

My similar example to the one mentioned above is from a Kyocera TASKalfa 2552ci KX copy machine. They can print to it over IPP for black and white, but in order to print in color a specific "Job Accounting ID" currently needs to be specified in the driver. I'm not aware of how to do this over IPP, so would I need to install a printer application for this purpose? Thanks.

michaelrsweet commented 1 year ago

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

michaelrsweet commented 1 year ago

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

tresf commented 1 year ago

if you have a printer purchased since 2010 then it is highly likely it will work without any printer-specific software.

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

tillkamppeter commented 1 year ago

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

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 get-printer-attributes IPP response (or whether another query is needed)?

tillkamppeter commented 1 year ago

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.

https://openprinting.github.io/achievements/#all-free-drivers-in-a-ppd-less-world---or---all-free-drivers-in-snaps

tillkamppeter commented 1 year ago

https://openprinting.github.io/about-us/ https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning