Open michaelrsweet opened 3 years ago
nahall
commented
1 year ago https://openprinting.github.io/about-us/ https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning
Thank you, the links are helpful to better understand how it will all work together.
michaelweghorn
commented
1 year ago @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?
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. [...]
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? (in which case it probably also makes sense to test with the CPDB backend for any missing options and issues, rather than testing the CUPS Job Ticket API directly to get an impression what issues might show up when switching)
tillkamppeter
commented
1 year ago 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 https://openprinting.github.io/current/#the-print-dialogs https://github.com/TinyTrebuchet/gsoc22/
klynastor
commented
1 year ago @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.
michaelrsweet
commented
1 year ago @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.
klynastor
commented
1 year ago Awesome; thank you for the insight.
MG-
commented
1 year ago 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. Tell me this is not a commercial boycot of old printers. I always found this program suspicious. Web-interface configuration only and on the fly overwriting config data... It has "problems" with automation of it's application in a full (open) system. It must be a real person.
zdohnal
commented
1 year ago @MG- Old printers are supported by printer applications, see other projects in OpenPrinting Github group - only their direct support in CUPS is being removed.
NJRoadfan
commented
1 year ago 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.
Dan-Essin
commented
1 year ago I have several comments: 1 - I have ONLY old equipment (like many others) and I'm not a linux or CUPS guru. It sounds like this will take something that "just worked" and turn it into another nightmare scenario for the less expert users. I envision an endless search on the web for solutions to problems that this will cause.
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.
michaelrsweet
commented
1 year ago @Dan-Essin To address your concerns:
The point of this work is to ensure that old equipment continues to work and be supported. I suspect enterprise Linux distros will continue to offer CUPS 2.x support for at least 5 years after OpenPrinting stops developing it. Per last week's OpenPrinting summit, the 2.5 feature release is still in the queue for 2024, so my guess is the last 2.5.x bug fix release will be in 2025 and the end of enterprise support no earlier than 2030. We aren't rushing things...
I will reach out to @tillkamppeter but I agree we should have a page talking about the many available printer applications that can be easily found.
The reason we are making changes is that there are things that are broken and features we cannot easily implement because of all the legacy crap. I know because I'm the one that chose to adopt the legacy crap over 20 years ago because it was expedient. So you can thank and blame me in the same breath! :)
These "new" IPP printers are already 13 years old now. And the alternatives are to have a really crappy user experience that only half works (stick with the old CUPS architecture), have two separate printing systems (like two separate desktop environments - you know how well that works...), or drop support for old printers (by far the simplest and cleanest solution, but it leaves many users behind...) We decided to do the extra work and spend the extra time to keep supporting old printers in a way that allows for a single printing system that can support all of the functionality of newer printers and applications.
MG-
commented
1 year ago @Dan-Essin To address your concerns:
1. The point of this work is to ensure that old equipment continues to work and be supported. I suspect enterprise Linux distros will continue to offer CUPS 2.x support for at least 5 years after OpenPrinting stops developing it. Per last week's OpenPrinting summit, the 2.5 feature release is still in the queue for 2024, so my guess is the last 2.5.x bug fix release will be in 2025 and the end of enterprise support no earlier than 2030. We aren't rushing things... 2. I will reach out to @tillkamppeter but I agree we should have a page talking about the many available printer applications that can be easily found. 3. The reason we are making changes is that there are things that are broken and features we cannot easily implement because of all the legacy crap. I know because I'm the one that chose to adopt the legacy crap over 20 years ago because it was expedient. So you can thank and blame me in the same breath! :) 4. These "new" IPP printers are already 13 years old now. And the alternatives are to have a really crappy user experience that only half works (stick with the old CUPS architecture), have two separate printing systems (like two separate desktop environments - you know how well that works...), or drop support for old printers (by far the simplest and cleanest solution, but it leaves many users behind...) We decided to do the extra work and spend the extra time to keep supporting old printers in a way that allows for a single printing system that can support all of the functionality of newer printers and applications.
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?
michaelrsweet
commented
1 year ago 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...)
jcpunk
commented
1 year ago 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.
michaelrsweet
commented
1 year ago @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...
Fell
commented
1 year ago 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.
Almost every printer manufactured since 2010 supports IPP/2.0 with standard file formats
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.
michaelrsweet
commented
1 year ago @Fell
Will I loose functionality if I upgrade? And if so, what do I need to do to keep operating my printer?
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...)
fallenguru
commented
1 year ago 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.
dptpirate
commented
1 year ago Brother HL-L2310D series (USB only) stopped working too.
zdohnal
commented
1 year ago @fallenguru Surely there will be distributions which will ship the printer applications as packages.
zdohnal
commented
1 year ago @dptpirate This issue is not implemented in CUPS 2.x, so the reason why your printer does not work is different from this issue.
dptpirate
commented
1 year ago @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?
zdohnal
commented
1 year ago @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.
dptpirate
commented
1 year ago @zdohnal Will do. Thanks.
Bitwolfies
commented
1 year ago "Yknow it makes sense to only properly support the open spec going forward, I wonder what those printing applications replacements ar-"
Snaps
Oh god why
sersorrel
commented
8 months ago As a user, I'm moderately confused by this message I just got:
(for the sake of Google, that says "Printer drivers and raw queues are deprecated and will stop working in a future version of CUPS.")
I set my printer up by clicking every "IPP Everywhere" button I could see, since I had a vague recollection that that's what worked last time, and from reading this issue it seems like that is meant to be the supported way of doing things. Is this warning a note that "your printer will break in the future when we remove this feature", or just a general "hey fyi if you have other printers that don't support IPP then you'll have a bad time"?
zdohnal
commented
8 months ago @sersorrel the message is about that specific printer not being installed as IPP Everywhere/or it (the fact it is IPP Everywhere) is not detected correctly - why does it not, it depends - please file a new issue on OpenPrinting CUPS and add more information about what you did and what is your setup. It is an off-topic here.
michaelrsweet
commented
8 months ago @Bitwolfies WRT snaps, that is one potential implementation for a Linux distribution - aside from native packages, printer applications can run inside Docker containers, QEMU-hosted VMs, etc. If Linux had a single ABI, architecture, etc. then it would be easy to provide standalone executables for each and run them everywhere as needed, but that hasn't happened and containers (of whatever flavor) are the best overall way to provide everything a given application needs without messing everything else up on your system.
And it is just for legacy printers - almost any printer released since 2010 supports "driverless" IPP printing so printer applications are only needed for the (very small and shrinking) number of printers that haven't adopted it.
tresf
commented
8 months ago And it is just for legacy printers
This statement is misleading. Brand new specialized printers still rely heavily on PPD and/or raw queues. This includes (but not limited to) Zebra, Epson, Citizen, Star, BOCA, and many others that either have no printer application, have no IPP Everywhere support, or are covered (in whole or in part) by an application (e.g. LPrint) provided generously by OpenPrinting.
michaelrsweet
commented
8 months ago @tresf See the text following that lead-in. Yes, there are still "specialized" printers that, after 26 years, haven't adopted IPP. Some are so limited (some receipt printers) that they can only print basic text over a 2-wire serial interface - those and other bare printers will likely never support IPP. The rest I expect will come around eventually - Zebra, for example, just updated a couple models with IPP support late last year...
But for existing non-IPP printers, printer applications are the way forward.
amarihw
commented
8 months ago Do Not remove raw queues.
tresf
commented
8 months ago Do Not remove raw queues.
It's a losing battle, but I wholeheartedly agree. 🍻
poscat0x04
commented
4 months ago @michaelrsweet
@tresf See the text following that lead-in. Yes, there are still "specialized" printers that, after 26 years, haven't adopted IPP. Some are so limited (some receipt printers) that they can only print basic text over a 2-wire serial interface - those and other bare printers will likely never support IPP. The rest I expect will come around eventually - Zebra, for example, just updated a couple models with IPP support late last year...
But for existing non-IPP printers, printer applications are the way forward.
The issue with printer applications is that some manufactures just haven't adopted it yet. For example my printer, Epson L3150, made in 2019, only supports printing over appsocket.
Realistically such low end printers will probably never have printer applications implemented by the manufacturers. To me removing support of print filters is equivalent to dropping support of my printer altogether.
Also, please don't use snap to distribute apps. It's basically only used by ubuntu.
fallenguru
commented
4 months ago The issue with printer applications is that some manufactures just haven't adopted it yet.
Has it ever occurred to you that some people might not want to run binary blobs direct from the manufacturer? Or even off-distro "open source" software direct from the manufacturer? I have no desire to have hundreds of MB of bloated spyware drivers, control centres, and whatnot on my system. No, not even in some sort of container.
tillkamppeter
commented
4 months ago The issue with printer applications is that some manufactures just haven't adopted it yet.
Has it ever occurred to you that some people might not want to run binary blobs direct from the manufacturer? Or even off-distro "open source" software direct from the manufacturer? I have no desire to have hundreds of MB of ~bloated spyware~ drivers, control centres, and whatnot on my system. No, not even in some sort of container.
We (especially the Printer Working Group (PWG) but also OpenPrinting) have done everything that this is not needed, asthere are standards for driverless printing, IPP Everywhere, AirPrint, Mopria, and many manufacturers follow them (in their hardware):
https://openprinting.github.io/printers
There are near 10000 know, driverless models.
Unfortunately, there are always manufacturers who think that this is not needed, or do not want it, to force their users to install their software (bloatware, spyware, ...). And printer manufacturers are big companies, one department building a nice driverless printer and another disguising it as non-driverless, to get the user install their software, which make the users pay a lot for original ink cartridges:
https://openprinting.github.io/OpenPrinting-News-June-2024/#most-hated-gets-loved-under-linux
Printer Applications, as a software emulation of a driverless printer to make a non-driverless printer work, replace printer drivers. But as most modern printers are driverless, so you only need to choose the right printer ...
fallenguru
commented
4 months ago We (especially the Printer Working Group (PWG) but also OpenPrinting) have done everything that this is not needed
No, on the contrary. By pushing (self-contained) "printer applications" and citing manufacturer adoption as a roadblock (therefore putting the ball in the manufacturer's lap) you're legitimising the practice of shipping such abominations instead of adhering to open standards. I realise that CUPS is multi-platform, but I'm a Linux user. And one of the neat things about Linux is that manufacturer's drivers are easily avoided, because everything is geared towards having devices either adhere to a standard or get the drivers included somewhere upstream. This change is promoting a more Windows-like printer driver paradigm.
[most modern printers are driverless]
Not really. Maybe many have some half-hearted IPP support, just enough that they can put it on the spec sheet without getting sued too much, but driverless IPP as a first class (all features accessible, on all ports, no bugs) method to access a printer is not ubiquitous.
you only need to choose the right printer ...
Brilliant. Problem is, nobody advertises driverless IPP, let alone as a prominent feature. Nor IPP Everywhere, for that matter. https://www.pwg.org/printers/ lists a grand total 1324 printers for me, currently. (AirPrint may be a de facto standard, but IDK how open it is, really, and how well it interoperates with other implementations.) So choosing the right printer has become hard, when it used to be as simple as getting something with support for PS (or later PDF).
michaelrsweet
commented
4 months ago [most modern printers are driverless]
Not really. Maybe many have some half-hearted IPP support, just enough that they can put it on the spec sheet without getting sued too much, but driverless IPP as a first class (all features accessible, on all ports, no bugs) method to access a printer is not ubiquitous.
OK, so any printer with the AirPrint logo on the box supports IPP and all key printing functionality via IPP. The certification tests are quite involved...
... Brilliant. Problem is, nobody advertises driverless IPP, let alone as a prominent feature. Nor IPP Everywhere, for that matter. https://www.pwg.org/printers/ lists a grand total 1324 printers for me, currently. (AirPrint may be a de facto standard, but IDK how open it is, really, and how well it interoperates with other implementations.)
AirPrint is IPP + Bonjour (mDNS and DNS-SD) + Apple Raster (a variant of CUPS/PWG Raster), JPEG, and (optional) PDF. So if the box has an AirPrint logo, it will work as a driverless printer with full functionality.
amarihw
commented
4 months ago What is going to be the replacement functionality for interface files? We produce over 18million postscript and ZPL print jobs a year to over 50sites.
We use interface files fairly substantially to apply logic, controls, filters and additional features that our ERP systems don't handle (printing wise) out of the box (like on the fly changing the word 'foo' to 'bar').
Is it going to be possible to apply programming to each and every print job per printer queue with bash/shell scripting? And if not, why?
Thanks
Central Services ▬ INFORMATION TECHNOLOGY ▬
@.**@.>
From: Till Kamppeter @.> Sent: Friday, July 12, 2024 5:49:57 PM To: OpenPrinting/cups-sharing @.> Cc: Wilkinson, Hugo (IT Dept) @.>; Comment @.> Subject: Re: [OpenPrinting/cups-sharing] Remove print filters and printer driver support (#4)
[https://image-processing-service.uk-1.mimecastcybergraph.com/v1/banners?encryptedData=oenPpPT6oEFNIxO%2FqG52ipObSkqcmUBeJ7XmavFhgM3BSfP8AicjEYgXEsF8UkakjGrliMNpc8gSw4%2Br0sysnY7Cn31qqA08zSW%2BvLt%2Bwt0cVPN7Bpo%2FvcXEu7Rwb18%2Ft0T5e1Ql7sXClBYfbvDrUDagOspjjSYakZC8Gr7%2BJBrvEDUeY6YLFSV6twrKNRy7QR5aY1DsxxzLSvsCk6WXSQrC3dqHTmAFyA9ImfFGRzfHLv%2BSWEjHp2gpood4LWrT3aU70Pq8Lo%2Fj62keRqqbVe99HlKqZT%2FZbIGnF7K4SxwgT9ICO%2FqIbMPoAuD28Gv7ss2%2FLdVLPxOgNBMfN4pkNCjMPb8%3D]https://report.mimecastcybergraph.com?magiclink=https%3A%2F%2Fapi.services.mimecast.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3DuEJX4ouxhqn8mWZjIsbnwOGxL9vSD5p1N2FB8O95sLhOCOAz%26state%3DeyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.gVEGpG-oUsTLBaDZASDXUW5dNhG1W0Ev--nf7nyTWNFfuZtvPtoM7JwG26A-OS1xc17AwOZp5er0lB8kqpghyyDhwWKb_xMu4R1owKiO0_CtoxBVH6AOTaO6UlCn-8VGqWYVMeFubMV2iMfE56lsx_SId2wUDG7eoZJ4WpRMARmH_h2qdVg_gKGl74qF9_GQnk9-SAFWS4n01ATcVV2T9dgtB7ZXUSzNH7sSscOQaxYoHq6sZ9VnyZUCgxCD1WDICFez9-2b5frtjDWdUhEgY7e60yCVK_lqMQug7wj2uVbNzegjGON6W0NpMP5J0IcJeqvd7GW6DnaDieHHL2W_-w.x0OtVYTtJzucx2nl.v5dQruRsNeI44czEzPyUt1mQ--6uuAB3FfgG1WXlaTPNdpIa4do6e-7Qq14dymvGxWNGKQSsYah30IgCvWkXulQu59iuWGY2rTccfOJh9pL6kc2r10LA_UrQv4GkNwaqe7Zuv2LvpHBTo_GTCPyuR8Q7Xu9M2TfnIqC2z_HSga1dvcml4V4EwbquFyi99inF82Cb0HgBTT1E__LYBlgkkap8Z_yTeGgD4JUjj1ld7C50iwixcscemPAtHWLoOwESwLFMPYl7xLDhq2MOBiKhGLJ9TTMaXFDedh4GmRhQTMCy741txf5O62ipqiuo6TZtZuTC0HUAutezJMcan976Z0_HdHkLa8yD-t8NvQj11OLtTJ3Ihma-h6fGzJdJutM729e0Ozfwa2bC_FA1RT-TsNFOZTeArFJmNfuMDKRxhPV2K75bPoX8Z2zFWUlarBhVc67PH3PUtFJSm39ZdsVHcDDulstIB022heSFMwxNgscmO5v1UU8ONO3azjwWAR4gHhVKuhtKZ3SOMYpte1-dk3ReBdTFRIqBb348GTaFVKZ3HR9RhsiGqw8NZxhleSht8lWJbmtZeiwVlPOR-4uK_ILvXwCOeMGP5Mah5_Alky9wptBLruJwQ0mbweJRZmm-g_9McomC3SwMVB_K8cnLQ3yuaBpsgnTytQO_AlQG3jGw53MAbJO-bFMcE0BtEP9jwu92rFDropXXHCbG-WdnL-gdelShLkz3zGks70rka9q6tC8TKOr3oBNh_0r0KTPJoAK4S8rBY5QhBOhKyAet8Ux0-SzyrxXyGTeNSq_Y8IykGhPrxXR8zbiqU4RNM7JRZxwOQK4fHrs0eIjSCoEoGO-i0AAzUzgo6WDH_frYSDJK.njXuRTn1exhi6uIjAQEJjw%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback CGBANNERINDICATOR
The issue with printer applications is that some manufactures just haven't adopted it yet.
Has it ever occurred to you that some people might not want to run binary blobs direct from the manufacturer? Or even off-distro "open source" software direct from the manufacturer? I have no desire to have hundreds of MB of bloated spyware drivers, control centres, and whatnot on my system. No, not even in some sort of container.
We (especially the Printer Working Group (PWG) but also OpenPrinting) have done everything that this is not needed, asthere are standards for driverless printing, IPP Everywhere, AirPrint, Mopria, and many manufacturers follow them (in their hardware):
https://openprinting.github.io/printershttps://openprinting.github.io/printers
There are near 10000 know, driverless models.
Unfortunately, there are always manufacturers who think that this is not needed, or do not want it, to force their users to install their software (bloatware, spyware, ...). And printer manufacturers are big companies, one department building a nice driverless printer and another disguising it as non-driverless, to get the user install their software, which make the users pay a lot for original ink cartridges:
https://openprinting.github.io/OpenPrinting-News-June-2024/#most-hated-gets-loved-under-linuxhttps://openprinting.github.io/OpenPrinting-News-June-2024/#most-hated-gets-loved-under-linux
Printer Applications, as a software emulation of a driverless printer to make a non-driverless printer work, replace printer drivers. But as most modern printers are driverless, so you only need to choose the right printer ...
— Reply to this email directly, view it on GitHubhttps://github.com/OpenPrinting/cups-sharing/issues/4#issuecomment-2225956259, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BHGB7ZHXDNSNBPXMRNRMH6DZMACLLAVCNFSM6AAAAAAT6J2KX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRVHE2TMMRVHE. You are receiving this because you commented.Message ID: @.***>
** Internet Email Confidentiality Footer **
Privileged/Confidential information may be contained in this message. If you have received this message in error you should, without taking any copies, immediately delete it from your system and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. All contracts for goods and services are subject to the terms and conditions of our relevant company, a copy of which is available on request or by visiting the company’s website.
Amari Metals Ltd. Registered in England and Wales number 2023155. Registered Office: Parkway House, Unit 6, Parkway Industrial Estate, Pacific Avenue, Wednesbury, WS10 7WP.
michaelrsweet
commented
4 months ago What is going to be the replacement functionality for interface files?
There is no official replacement.
Is it going to be possible to apply programming to each and every print job per printer queue with bash/shell scripting? And if not, why?
The short answer is security - allowing arbitrary software to be loaded (potentially from a remote client) onto a server with few (if any) restrictions on the run-time environment is a bad idea.
That said, it is possible you will be able to make use of the accounting/managed printing interfaces (still to be defined - we don't have a lot of resources/developers to do this stuff) to extend things at your sites. But the focus is 100% on standard formats and not on legacy/proprietary formats like PostScript and ZPL.
tresf
commented
4 months ago What is going to be the replacement functionality for interface files? We produce over 18million postscript and ZPL print jobs a year to over 50sites. We use interface files fairly substantially to apply logic, controls, filters and additional features that our ERP systems don't handle (printing wise) out of the box (like on the fly changing the word 'foo' to 'bar'). Is it going to be possible to apply programming to each and every print job per printer queue with bash/shell scripting? And if not, why?
I asked a similar question here: https://github.com/OpenPrinting/cups-sharing/issues/4#issuecomment-1386031531
This was @michaelrsweet's response:
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 too am concerned about this. What's particularly off-putting are terms like "vertical market printers", which suggests that these are "special needs" customers, quoting [source: investopedia]:
"A vertical market is a business niche where vendors provide goods and services to a specific group of customers or industry with specialized needs. [...]"
This buzzword sounds very reasonable at a glance, but just to focus on ZPL alone, shipping services such as DHL, FedEX, UPS, USPS, Royal Mail still offer ZPL as a label format because it's smaller, faster and more reliable than an PDF. Where the term "vertical market" starts to go sour is when we look at services such as Amazon Vendor Services, where SOHO users on Mac, Linux and Windows are printing their own labels. There was once a time where shipping was largely a "vertical market", but now raw printing is in the hands of millions of end users.
The way that Windows handles this problem -- in the scope of ZPL -- is that the Zebra driver -- written and maintained by Zebra Technologies -- detects the raw data and sends the ZPL directly, however the ZPL driver in CUPS doesn't have this feature, requiring some form of raw bypass -- either on the application level -- or on the OS level.
My fear, and I've stated this before, is that removal of raw communication will force these users to switch to Windows.
Note, although ZPL is used as an example, this raw functionality is still very popular for other formats (CPCL, EPL, ESC/POS, FGL, JSCRIPT, StarPRNT).
With regards to the bloatware/spyware claims, this is largely untrue for the industry printers and drivers and -- in my experience -- is more of a problem with gigantic software bundles provided with MFPs. I think it's important to quantify any arguments for or against the adopt of IPP when calling out vendors because not all drivers are intended to force the purchase of ink cartridges -- especially those printers (e.g. label, receipt, ticket) that don't use ink.
Also -- unrelated, but great news -- HP has FINALLY backpedaled on this: https://www.tomshardware.com/peripherals/printers/hp-discontinues-online-only-laserjet-printers-in-response-to-backlash
Lastly, as an advocate for keeping RAW, I want to be careful to NOT sound minimizing and NOT sound unappreciative to AirPrint/IPP Everywhere. Everyone I encounter really enjoys using AirPrint and avoids the printer driver whenever possible. For example, I've been a Windows ARM user for several years and this provides a way to use hardware that may never receive an official driver from the manufacturer. This is revolutionizing and simplifying the way we print. That said, I just really, strongly feel that RAW printing will be needed side-by-side this functionality.
michaelrsweet
commented
4 months ago @tresf
I too am concerned about this. What's particularly off-putting are terms like "vertical market printers", which suggests that these are "special needs" customers, quoting [source: investopedia]:
"A vertical market is a business niche where vendors provide goods and services to a specific group of customers or industry with specialized needs. [...]"
This buzzword sounds very reasonable at a glance, but just to focus on ZPL alone, shipping services such as DHL, FedEX, UPS, USPS, Royal Mail still offer ZPL as a label format because it's smaller, faster and more reliable than an PDF. Where the term "vertical market" starts to go sour is when we look at services such as Amazon Vendor Services, where SOHO users on Mac, Linux and Windows are printing their own labels. There was once a time where shipping was largely a "vertical market", but now raw printing is in the hands of millions of end users.
So really, relying on a vendor PDL for a mission-critical printing application (shipping) has never seemed a safe result to me. ZPL compatibility between printers/vendors is not 100%, and I've done enough development and support over the years to know that "raw printing" causes as many problems as it solves.
All of the major shipping companies support PNG label images (and honestly most PDF output consists of an image embedded in the PDF with some extra text added around the label), which is why LPrint is so keen on supporting it as well as ZPL, EPL, etc.
The way that Windows handles this problem -- in the scope of ZPL -- is that the Zebra driver -- written and maintained by Zebra Technologies -- detects the raw data and sends the ZPL directly, however the ZPL driver in CUPS doesn't have this feature, requiring some form of raw bypass -- either on the application level -- or on the OS level.
CUPS absolutely supports this, it is just that auto-detecting ZPL as a general thing is not particularly accurate - you can add MIME typing rules to your CUPS system to get it to auto-detect your particular files, and LPrint also has specific detection rules for each type of label printer it supports.
My fear, and I've stated this before, is that removal of raw communication will force these users to switch to Windows.
I don't see this myself, as Windows is not particularly reliable and is different enough to make porting whole systems from Linux/Unix. Also, LPrint exists and supports the most common label printers already.
Note, although ZPL is used as an example, this raw functionality is still very popular for other formats (CPCL, EPL, ESC/POS, FGL, JSCRIPT, StarPRNT).
CPCL, EPL, and ZPL are already covered by LPrint.
ESC/POS (and its replacement) is coming in a future LPrint release.
It isn't clear whether adding FGL, JSCRIPT, or StarPRNT support is worthwhile since I've had no requests for them.
But as I keep stating, "raw printing" isn't something we will support going forward - it simply doesn't scale and isn't at all secure for a printing system that has to support a wide variety of printers. Printer Applications are intended to bridge the gap to safely allow support for vendor PDLs while also providing support for standard PDLs so that all applications can make use of a printer, not just an esoteric site/vendor application that is unable to properly support the printers it uses.
tresf
commented
4 months ago So really, relying on a vendor PDL for a mission-critical printing application (shipping) has never seemed a safe result to me.
Well, you're entitled to your opinion, but I think the term "safe" is quite misleading here. What I believe is being inferred is that the contract between the application and the printer is broken when you largely bypass the queue status information. In that regard, I wholeheartedly agree. Application developers need to put special code in place to handle queue events and this experience is sub-optimal.
However, this "safety" is so very misleading of a word because despite the hardware variances in PDL handling (not to mention DPI variances), this must be weighed in an organization against the performance and reliability costs of formats such as PDF or raster and in my experience, this decision is best left up to the organization to decide.
I'm admittedly biased in this dialog -- and for that reason, I apologize for repeating several points over and over -- but I work with 800 companies across millions of PCs to help with these decisions and after testing and analysis, ZPL is often preferred. While I do provide these pros/cons to customers, I do not make the decision for them. As long as there's a choice, I allow the users to make an informed decision.
ZPL compatibility between printers/vendors is not 100%, and I've done enough development and support over the years to know that "raw printing" causes as many problems as it solves.
Some will say IPP Everywhere/AirPrint suffers an identical problem! I'm trying to be civil here, but it's taking a long time for these vendors to have feature-parity even when it DOES work. Out of politeness, I mention the times it DOES work, but in many cases, we've reverted from AirPrint/IPP Everywhere to the vendor drivers because of a botched implementation -- hundreds of gibberish printouts for a single PDF because the AirPrint support mysteriously breaks on certain desktops. This also ignores the fact that the mappings just stop working under certain scenarios (removing and re-adding the printer often fixes this). There's also an auto-magic problem users are dealing with since the tech can work without IP Addresses as all. But I digress, the point of this conversion is NOT to talk about the shortcomings of AirPrint and friends -- that will get better with time -- but rather to talk about the impact of removing filters.
CUPS absolutely supports this, it is just that auto-detecting ZPL as a general thing is not particularly accurate - you can add MIME typing rules to your CUPS system to get it to auto-detect your particular files, and LPrint also has specific detection rules for each type of label printer it supports.
Thank you for sharing this information. I've yet to test LPrint, but if it handles this scenario rather gracefully, it would be a huge improvement over the existing driver.
I don't see this myself, as Windows is not particularly reliable
Anecdotal, but most organizations use Windows for it's reliability in printing. This is often due to the fact that device drivers are more prominent there, but I think "reliable" is misleading. In my experience, Windows is a very reliable printing experience, but often the stacking of 20 years worth of device drivers causes system and printer instabilities, but I believe this to be orthogonal to the OS and rather simply a reason for adopting AirPrint/IPP Everywhere, NOT a reason to drop support for raw queues and not related to the usefulness of raw queues as they continue to exist on other OSs (rather manually added raw queues or via driver detection).
If CUPS continues to support the raw queues -- albeit through a different pipeline -- I agree, this won't be a reason to switch. I owe it to you and the OpenPrinting team to test the feasibility of this approach.
raw printing" isn't something we will support going forward LPrint also has specific detection rules for each type of label printer it supports.
It's these types of statements that add confusion. Is the intent to ONLY allow raw printing when a specific printer application has been coded to accept it? It sounds like support will be maintained -- in some form -- through these applications. What's not obvious is what options are available when these applications aren't available.
Regarding FGL, Ticketmaster and Livenation use this format, so it's still a rather "vertical industry" so they'll probably just keep using Windows, but there also a lot of smaller ticketing companies that use it that would be more inclined to use a CUPS solution if one were available. Still "vertical" -- since it's just much less likely for an individual (e.g. SOHO) to own FGL-capable of hardware, whereas label printers are becoming more and more common.
michaelrsweet
commented
4 months ago @tresf
However, this "safety" is so very misleading of a word because despite the hardware variances in PDL handling (not to mention DPI variances), this must be weighed in an organization against the performance and reliability costs of formats such as PDF or raster and in my experience, this decision is best left up to the organization to decide.
You do realize that malicious ZPL can brick your printers, right?
But in any case, I don't think we disagree on who should choose the format to use - LPrint was explicitly designed to support both vendor PDLs and standard PDLs for this very reason, while providing standardized status monitoring, etc. "Raw" support cannot come at the expense of standard printing, and since the raw applications are unwilling or unable to develop their own printing infrastructure, this is the best compromise I can provide.
raw printing" isn't something we will support going forward LPrint also has specific detection rules for each type of label printer it supports. It's these types of statements that add confusion. Is the intent to ONLY allow raw printing when a specific printer application has been coded to accept it? It sounds like support will be maintained -- in some form -- through these applications. What's not obvious is what options are available when these applications aren't available.
So to be explicit about this:
The goal is simple: all CUPS printers can be used by any application. If you have an application that supports a/the native PDL of a printer, it can use it, but otherwise it uses a standard PDL to still be able to print.
Regarding FGL, Ticketmaster and Livenation use this format, so it's still a rather "vertical industry" so they'll probably just keep using Windows, but there also a lot of smaller ticketing companies that use it that would be more inclined to use a CUPS solution if one were available. Still "vertical" -- since it's just much less likely for an individual (e.g. SOHO) to own FGL-capable of hardware, whereas label printers are becoming more and more common.
Last time I checked there are only two vendors left supporting FGL - Boca Systems and Microcom Corporation. If someone provided a printer or other support then I could probably add it to LPrint pretty quickly. But like I said I've had nobody ask or offer... :/
tresf
commented
4 months ago I'll reach out to BOCA today with this feedback. I've been in communication with them over the years... here's a quote from 2023:
I'll link them to this bug report to see if they have resources to help get support added.
poscat0x04
commented
4 months ago Raw queues used for shared printers require client software to talk directly to the server to get the printer capabilities, which breaks when sandboxing/AppArmor/SELinux is used
btw I'm using epson-inkjet-printer-escpr just fine on fedora (which has selinux enabled).
PPDs and drivers have been holding us back from offering better user experience (ready media, localization, full range of printer options/values), improved document processing, and improved accounting
Are there any reasons CUPs can't support printer filters/drivers with degraded functionality? Surely degraded functionality is better than not supporting it at all?
michaelrsweet
commented
4 months ago @poscat0x04
Raw queues used for shared printers require client software to talk directly to the server to get the printer capabilities, which breaks when sandboxing/AppArmor/SELinux is used
btw I'm using epson-inkjet-printer-escpr just fine on fedora (which has selinux enabled).
Not applicable - a SHARED raw printer requires the client application to directly communicate with a remote server, but some environments restrict outgoing network connections for security reasons (depending on the application, etc.) The local spooler, however, has networking enabled and can indirectly provide access to such things. In the current CUPS 2.x architecture, that requires a local PPD and queue.
PPDs and drivers have been holding us back from offering better user experience (ready media, localization, full range of printer options/values), improved document processing, and improved accounting
Are there any reasons CUPs can't support printer filters/drivers with degraded functionality? Surely degraded functionality is better than not supporting it at all?
There is a history of bugs, regressions, and security issues around raw queues. And it is not just “degraded” functionality but outright broken functionality when an application sends a file that the printer cannot understand and spews out a whole ream of paper with random characters on it.
Is there a reason why you need a “raw queue” and need CUPS to support that functionality? I understand the need (in some cases) to support sending a proprietary file format to a printer (and that functionality will remain), but why do you need a queue for a printer that otherwise cannot be used?
I am reminded of a hack an Apple engineer did very early in the development of macOS - that engineer wrote an interface script that played music files and had CUPS function as a primitive jukebox. It was certainly an interested trick but was not a very useful or efficient solution that could (and did) break with a change to the printing system or OS security model. Using CUPS to spool files to be sent to a random hardware device with no safety checks, processing, or status monitoring is just asking for trouble. It has never worked well, and has frequently resulted in unexpected behaviour even for the people setting the queues up.
tresf
commented
4 months ago I'll reach out to BOCA today with this feedback. I've been in communication with them over the years...
@michaelrsweet Re: FGL drivers and raw support: BOCA replied with gratitude, and asked for me to share their engineer's email address with you. I've forwarded the information to you via email (gmail) and will reply to them with the same.
amarihw
commented
4 months ago Thanks Michael / Tres / poscat.
Is there any scope for the insane idea of simply having the "new CUPS 3.0" code along-side the current code (but being the default code), but then 'cupsd.conf' having a flag in it like:
useOldCode = yes/no
and then those of us that want to continue using the 'insecure code' can do so whilst not either having to move to a port of CUPS or having to manually maintain an older version of CUPS to run outside of package managers etc?
I must say this feels like an escapade for the sake of being an escapade - no-one's died or had a high-profile job loss in 20+ years from using raw print queues and interface-files 🙁
Thanks and regards
Central Services ▬ INFORMATION TECHNOLOGY ▬
@.**@.>
From: Michael R Sweet @.> Sent: 15 July 2024 12:33 To: OpenPrinting/cups-sharing @.> Cc: Wilkinson, Hugo (IT Dept) @.>; Comment @.> Subject: Re: [OpenPrinting/cups-sharing] Remove print filters and printer driver support (#4)
[https://image-processing-service.uk-1.mimecastcybergraph.com/v1/banners?encryptedData=ba8D0KoTm3PsgvCaHT0Hfqu9lCKwrAFdWJ9Lbghmk0Mrlf313mxXJQuLUEHdb0BUDtE89rE3JjX0ANKzIzqZZRA6BS%2BeE8LphRWmBKOJweM3KSnmjsEgVvk%2FIkZFUwKONVUKTxooDTWExNuKalxAIt53DN2kxA9ZcTM9ETdQ6CcuN6H%2FCv4sxU4XlBck1EgOGTvL7D14%2BOu%2FNGXZv9QmPSi%2FCUY8SVn0mjxQXtEFFkI%2BvZ0vJ4C2MX3iCJqs0E9ihVraAYM8h00AuTxLIJuh1K3PXQLpoQPCHUTHIOIgMspwq%2F7QBKueQl9MH4sDzHhHynwiZG4ywmKm%2BHMHRChZSrONb%2FE%3D]https://report.mimecastcybergraph.com?magiclink=https%3A%2F%2Fapi.services.mimecast.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3DuEJX4ouxhqn8mWZjIsbnwOGxL9vSD5p1N2FB8O95sLhOCOAz%26state%3DeyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.h_vRisgpgy06yscq07OugHEZZw6QUyasfkpyhi7_ec2ffXKNlfqwihXwTROvAhnSfBAPuj2JyYe5OzTSjAObpGeQCiqDRo12AmTuy1M2OGyCzmB31zBt0ltvgZZ2OcYQx0Ye3LIJJyhl3JRn5YUzENqPmaSlzYsrhX3267OWsY-VG4BiUNci-rdBmga7w5PJRvulCWCTrMyYmyOWWnvN8sdfoyIu-RyJGo1krQeyZGwaNrjdbqsjK3vVALgCq86cUunRPNyw-j4I6NVvhUg4Y8dBnw6_1r-E_oWhZ1v8dJuMQlf8gR7VjGwWaZGC-2_hBVTvhFSy3zOH3cj4fIR_Jw.AnN8NVKDEMJ_rrO9.kBGJWFzflqJR0jJ79DuQnuBRSrQ7nY_UGP5BgZ6KQQ4Rl1vFX4j0QOraxHZzfXFWS6bY4Jk4YCTlyw3s2JIZsdc7KIr3DpopW6xcM5KHN77rACfTH6LR8wLbkUsrrxgqDxw6-nTfDbEN3YzhsSP0nxLS6-qo--HCtSDYUrbDUj0EC-XxJVYvqW20TtMaoqUWeRXBxaVjz9cNj59oWvFia5HQiNCz9Nfl8iMDphazwoNtnO3WTRMb7WlbQ6spaG_taI5_XK_11tDKPzRGMyEzydnYgfPVedoJqvHwusCUqdlHU2Ci2ZlqWv-isYuytdDdGf0v7zWFRnE2z3SIYLRRyZZWJuubMWUesQ3WfsE_zm0XZUZ0WyzSVJm5Z253chGjLXUrvOFimrjEjCbJZpJjWksTqietO7ZTsLwTboxVXR-PRWJs_LKkuCQx8j3RXWHgrMScb4TKF81KEgcfRDyPa9SHu_tOXGmH0m5QlcaZhhG6-DtyTab-k1jBbF-ODcCutzpjIkTipzSMHu0VSQtnCU3vTjKF3YCWnxzShK0zwsGi4dEjSmk6FcWIwT-FfyUbuYxRwQ0xB5BuCLPAmuYvjPCcI6DdOJqBLVwAJg2HJigMEEDLRcuoCcRtlbZpFJyyAm10bGUfc9ShM7Kox4S8LWfPsb-II9uWdbcbaaPxqxEmI0rvAi8dZK5NQp-nXqDloGWOVvwJjyTltWOt8R7-pTE372CE4jtoK7crDebFCzOHCBYs0guNWVyaPrZZNNRvCxjSTV0n481sbLWoMspx38y7LHDHwLhTTflo7dgB0-kKpmZm2Nks-D9kjps7f-Oj-WR5nz_InBfTGwQmnhZGWkSRYWaOBRT1zb6Wm8JJ_8kl.sWC_mD6JaHV50ju9qDOPMw%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback CGBANNERINDICATOR
@poscat0x04https://github.com/poscat0x04
Raw queues used for shared printers require client software to talk directly to the server to get the printer capabilities, which breaks when sandboxing/AppArmor/SELinux is used
btw I'm using epson-inkjet-printer-escpr just fine on fedora (which has selinux enabled).
Not applicable - a SHARED raw printer requires the client application to directly communicate with a remote server, but some environments restrict outgoing network connections for security reasons (depending on the application, etc.) The local spooler, however, has networking enabled and can indirectly provide access to such things. In the current CUPS 2.x architecture, that requires a local PPD and queue.
PPDs and drivers have been holding us back from offering better user experience (ready media, localization, full range of printer options/values), improved document processing, and improved accounting
Are there any reasons CUPs can't support printer filters/drivers with degraded functionality? Surely degraded functionality is better than not supporting it at all?
There is a history of bugs, regressions, and security issues around raw queues. And it is not just “degraded” functionality but outright broken functionality when an application sends a file that the printer cannot understand and spews out a whole ream of paper with random characters on it.
Is there a reason why you need a “raw queue” and need CUPS to support that functionality? I understand the need (in some cases) to support sending a proprietary file format to a printer (and that functionality will remain), but why do you need a queue for a printer that otherwise cannot be used?
I am reminded of a hack an Apple engineer did very early in the development of macOS - that engineer wrote an interface script that played music files and had CUPS function as a primitive jukebox. It was certainly an interested trick but was not a very useful or efficient solution that could (and did) break with a change to the printing system or OS security model. Using CUPS to spool files to be sent to a random hardware device with no safety checks, processing, or status monitoring is just asking for trouble. It has never worked well, and has frequently resulted in unexpected behaviour even for the people setting the queues up.
— Reply to this email directly, view it on GitHubhttps://github.com/OpenPrinting/cups-sharing/issues/4#issuecomment-2228285377, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BHGB7ZG5RYUHNCG6ZNQWBODZMOXPJAVCNFSM6AAAAAAT6J2KX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRYGI4DKMZXG4. You are receiving this because you commented.Message ID: @.***>
** Internet Email Confidentiality Footer **
Privileged/Confidential information may be contained in this message. If you have received this message in error you should, without taking any copies, immediately delete it from your system and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. All contracts for goods and services are subject to the terms and conditions of our relevant company, a copy of which is available on request or by visiting the company’s website.
Amari Metals Ltd. Registered in England and Wales number 2023155. Registered Office: Parkway House, Unit 6, Parkway Industrial Estate, Pacific Avenue, Wednesbury, WS10 7WP.
michaelrsweet
commented
4 months ago @amarihw
Thanks Michael / Tres / poscat. Is there any scope for the insane idea of simply having the "new CUPS 3.0" code along-side the current code (but being the default code), but then 'cupsd.conf' having a flag in it like: useOldCode = yes/no and then those of us that want to continue using the 'insecure code' can do so whilst not either having to move to a port of CUPS or having to manually maintain an older version of CUPS to run outside of package managers etc?
No.
It isn't like the new code will contain the old code. If you want to continue getting the CUPS 2.x experience, you need to continue running CUPS 2.x.
amarihw
commented
4 months ago And just for the record and people's general consumption, as of July2024, CUPS v2.1.4 is the last version which has both raw queues and interface file support, and which you can successfully compile using modern libraries on Redhat9 and Ubuntu 24 LTS.
(On Ubuntu 24 you have to skip the kerberus support by using '--disable-gssapi' when building).
Thanks once again all and good luck.
Central Services ▬ INFORMATION TECHNOLOGY ▬
@.**@.>
From: Michael R Sweet @.> Sent: Wednesday, July 17, 2024 10:32:06 PM To: OpenPrinting/cups-sharing @.> Cc: Wilkinson, Hugo (IT Dept) @.>; Mention @.> Subject: Re: [OpenPrinting/cups-sharing] Remove print filters and printer driver support (#4)
[https://image-processing-service.uk-1.mimecastcybergraph.com/v1/banners?encryptedData=pztGL6C%2B87bYpcJepkEngtq%2FCaaMXspj%2FvSRQZ4KkfJDpe0oQDzvvkQRg87RqKqORiNJK1kL0cXnSoyhNaPQ96RjQlFeHdJFj9Ck8rGDASLIqyoi%2BfspAP4x65tDZBN1AnelD4mOIWiUkKKWU4v2Ea5ZmTdw%2F0vaqy7vQPTa%2BE1fR2oCfar9%2Fg7H%2BFPB3z5lHx%2BRRairQEv3lq%2B%2BRK55VSSJrwwF6E6vvosQO82upWuCH4Td5T7MzQhFaPR8zu5mx2VRJJU%2FtttdB1LahqeYF8OG%2BAFTL2IDXd6is6V%2FSxjx8iL4L88gkkS9Fk4fkQyQCcRAIapLTSWAy3tUuPlQoCcPojc%3D]https://report.mimecastcybergraph.com?magiclink=https%3A%2F%2Fapi.services.mimecast.com%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3DuEJX4ouxhqn8mWZjIsbnwOGxL9vSD5p1N2FB8O95sLhOCOAz%26state%3DeyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIn0.rh_MP81TTSX3812hF6V1vMIaK6tEwV6bwY3QFLTvtJ5UgsK1hDCoXQ29jRrDDqSe8N-CjZO3VLK-SjJaRZRdrIAZoYM-k1jbY-u17Be4Q1SJFL4viYQhIJ0n7TR5t9XjgFTnc8CWKKoQucQRDCUh8an3XOBI9_PVdus4R00GHMJTXAEpzotL1qd9cs_LCqpfYSNGVD8X2JLtJYnkdFuHqW9ipY8uj2ikRH6wOMneiHeaHXjf8GeZ-IvXJm9IliUE24Ls7a4E2Rt48ONYYrNWJbJkybeWJ3pHXavSiUb766eD0zkIfpC3muepf4RZqhzx0A4M_l60TztSIaplJAkQNw.JxDFPm8R6YJFwKzg.PrB23ra38KRxZcfnVucB9q4uaQtFSvrPQWgKhp7_4bHmNXI6iYEIpKvVpu3wsMAJI7lxPhoP62injC0dOMVHiXueH96NID2hjI0N85aJjP92Tg_QJPSRJxy1Xums3U9ubD8d8crT8JMNINyfGBfdbaWyrZPXg0gN49EF9skYQnXaqxImBm9UIvV4BuOwO-XHSggc_n-AyqYeUGh7VtblL98xFaWaigFeLX3Yclvl1m7KkFkFaqP5WW7jfRb_yF-L4XUBKCBqKI1y2Efih6iHZwUm7kMDhO5ZdoYlwP-Zony8gMmNr07iibcB6T_D1v5qyWf3XFo8V-w1740d0fDDN6qIkK53o3j3LjxdoHDvmQi-YBa8__M75GmMZucsceUEL0MIc4X1fu0WpwCrRT6FJzYRjQLElfePZN7CRknjrHtlftBZdyzEbczADmCOO1pCAZ9sFQKWYaah3CnVi_Zp8oh_PvrjRLqyjPSNBcp7exEjRQpf4c6BOjPB7VonaaV-Tp_C8kFgKjmtGznPEvzRh4iSFAPBfixZe6Xt5sjPo3TJOAQAufeVNYLLfJXW6STvgRck1Oxa_ixeZ8O2utMRNO-U-bJDLByFRJTQh1yKkENNrMY45YKEIyqBF0ZVa_zlUG90bcXihKa4LeenU3pVbj2RSH8QHuMOUqju8-EsuuwdeAaI5bQMSUSqF3wpajBKcy1eA8vLDp6iF5V4_bhLLik4nHxkeiZ5s80UtbtWv_5C3CO--qBgyqwIhrqNxzfm3sXLpwq7lSVNW7gL18j7SQzWGIfEeBIzLTImupDBlHhLdTchVGTFIsVPyTfQrchq7vOz5LQUxHBBCCpKZOapKx2YlN1F6QgpjIOizvJEEPiR.MB0VOFynbPb6xMPPYrx1nQ%26redirect_uri%3Dhttps%3A%2F%2Freport.mimecastcybergraph.com%2Fcallback CGBANNERINDICATOR
@amarihwhttps://github.com/amarihw
Thanks Michael / Tres / poscat. Is there any scope for the insane idea of simply having the "new CUPS 3.0" code along-side the current code (but being the default code), but then 'cupsd.conf' having a flag in it like: useOldCode = yes/no and then those of us that want to continue using the 'insecure code' can do so whilst not either having to move to a port of CUPS or having to manually maintain an older version of CUPS to run outside of package managers etc?
No.
It isn't like the new code will contain the old code. If you want to continue getting the CUPS 2.x experience, you need to continue running CUPS 2.x.
— Reply to this email directly, view it on GitHubhttps://github.com/OpenPrinting/cups-sharing/issues/4#issuecomment-2234356476, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BHGB7ZFE4GEZ5ARL7UB3EHLZM3PFNAVCNFSM6AAAAAAT6J2KX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZUGM2TMNBXGY. You are receiving this because you were mentioned.Message ID: @.***>
** Internet Email Confidentiality Footer **
Privileged/Confidential information may be contained in this message. If you have received this message in error you should, without taking any copies, immediately delete it from your system and kindly notify the sender by reply email. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. All contracts for goods and services are subject to the terms and conditions of our relevant company, a copy of which is available on request or by visiting the company’s website.
Amari Metals Ltd. Registered in England and Wales number 2023155. Registered Office: Parkway House, Unit 6, Parkway Industrial Estate, Pacific Avenue, Wednesbury, WS10 7WP.
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: