FUTURE: Remove printer driver and raw queue support. #5271
Comments
|
This looks a bit scaring without a planned date or CUPS version In #5269 the commit The "raw" model is deprecated and will not be supported in a future version of CUPS. In #5270 the commit PPD files and printer drivers are deprecated and will not be supported in a future version of CUPS. I would like to know at least a currently estimated date or CUPS version |
|
In issue #5270 you wrote that
Their may be also special printers that are supported only by a special (proprietary or custom) software, which cannot easily integrated into cups. Printer drivers should not disturb that printer code by changing it in any way - cups should just queue it and forward it unchanged to the printer. This is what raw queues are for. The code for processing printer drivers and raw printers are already in cups, and it is working since many years. Why will you remove it and make many printers unusable, or force users to use old cups versions? Please leave the code in cups, it already exists and is working, and I think that IPP Everywhere can coexists with the old code, as an alternative. You may document that the new interface should be used for new printers, that's ok. Another possibility would be that the code for printer drivers and raw printers will be transferred to another (new?) project in a way that it can be easily integrated into cups, like an add-on or other printer drivers. |
michaelrsweet
changed the title
|
@jsmeix @imsedgar This is a future planning issue, not a notice of impending changes. I will update this issue with some of the details ASAP, but we will be discussing this in detail at the May 2018 Open Printing Summit/PWG meeting. |
|
@michaelrsweet "future planning" looks much less scaring ;-) Nevertheless I wonder if printing really could work I guess manufacturers will always develop new kind of devices By the way: On Mon, Feb 19, 2018 at 11:37:23AM +0100, Johannes Meixner wrote: > As far as I know PPD files are declared "deprecated" at CUPS upstream > (but PPD files will still be supported by CUPS for a longer time) > and current CUPS provides newer APIs for that functionality. ... Unfortuntely, those "newer APIs" appear to only be suitable for printing *clients*. For those like Gutenprint who are trying to write printing *drivers*, the PPD APIs are all we have to work with. Solomon Peachy |
|
@jsmeix It can and does work for billions of mobile devices in the wild today. And (2D) printing is not exactly a new industry - the vendors developing the printers are also the ones developing the standards we rely on, to the point that the IPP workgroup is left addressing edge cases, writing testing tools, and clarifying existing specifications. As for Gutenprint, with all due respect I started that project and have done things before that Robert and others claimed were infeasible or impractical (Mini-XML to replace libxml2 plus the whole CUPS filter, backend, and driver interface to make Gutenprint a system-wide driver instead of just a Gimp plugin). Putting an ippserver wrapper around Gutenprint is trivial, the only "challenge" will be doing a decent UI for all of those controls. |
|
@michaelrsweet I have a general understanding question: Is my understanding right that future CUPS (without built-in driver support) If my understanding is right, it would mean that any physical device Is my understanding right? |
|
@jsmeix Yes, an IPP Everywhere printer application (or even a hardware box - several companies have them for AirPrint already) can provide a compatible interface for any CUPS 1.4 or later client. |
|
I have one more general understanding question: As far as I understand it such an "IPP Everywhere-compatible Printer instance" Accordingly when CUPS requires that its recipient must be an But when CUPS acts only as a client I wonder if there is still a reason If my understanding is right, for usual end-user use cases it should be I could imagine a cupsd "in between" the printing application and the |
|
@jsmeix Please do attend (either in person or by calling in) the 2018 Open Printing summit, where I will be talking about these issues. Basically, CUPS can't just be the client library because we still need background spooling and file conversion, even with IPP Everywhere. And we don't want to keep PPD files and printer drivers around - yes it is technically possible, but it also retains all of the limitations we have today. The SAP use case is not valid - even a simple client spooler could handle thousands of jobs in a short period of time, with IO speed being the primary constraint. I do envision a dedicated CUPS server that is focused on enterprise functionality like access control, accounting, release printing, high-speed RIP capabilities, etc. This server would be the front-end for other IPP Everywhere printers that are not directly accessible from clients, and support things like the IPP Shared Infrastructure Extensions so that those printers could be anywhere in the world. But this server would only get used on servers, not clients... |
|
Gutenprint already has the old GTK-based UI (libgutenprintui2); perhaps it will be possible to use that at least for prototype purposes. |
|
i would like to see some more discussion about deprecating CUPS PPDs. Airprint has very limited functionality compared to an actual printer driver. For a mobile phone this may be acceptable (barely) but i don't foresee that users will accept this limited functionality. I did not make the printing summit but will be reading up on the topics. IPP Everywhere is apparently nowhere near providing the kind of functionality corporations are looking for. A lot of related software directly ties into PDLs and PPDs. Example: all print accounting software has to be able to parse the print data, most of that software runs on windows servers. How do you picture this will work without drivers and printer languages like Postscript, when 10s of thousands of MAC users that currently send Postscript jobs via SMB or LRP to a Windows server switch over to "Airprint"? or IPP Everywhere? I am pretty sure my customers have no idea this is coming.... |
|
@UliWehner AirPrint isn’t a public specification, but it is based on IPP and absolutely covers all important driver/printer features (just not “red eye removal” and other features that don’t belong in a driver anyways). That said, this is a bug for tracking the future removal of driver support. PPDs have been deprecated for 10 years and drivers were just deprecated for CUPS 2.3 - we are not rushing into this and there will be ways to support legacy printers when CUPS stops supporting drivers, just not directly through CUPS. |
|
Printers can easily last 20 years, please do not implement this feature. |
|
@Michael-IDA We are not eliminating support for 20-year-old printers, we are just planning to move support for such printers to dedicated applications/services so that we don't have to drag around the 30+ year old PPD metadata that is preventing us from fully supporting modern (less than 10 year old) printers. |
|
Hi Michael, (@michaelrsweet) Sorry for what probably came across as grumpy? As pretty much an ignorant individual IRT CUPS, the synopsis at the top reads to me as: A) CUPS is removing the code for PPDs and {whatever else?} is needed for printers not using {IPP?}. If B) is actually the CUPS project’s intentions, then old printers are just ‘shit out of luck’ as no one is going to create dedicated applications/services for a few one off printers. Especially since these printer ‘use to have’ a methodology that made them functional. While installing old versions of CUPS is viable, at some point that will also entail the user having to install old version of the OS, with all the resultant security nightmares, to satisfy the old version of CUPS’ requirements. If B) is not true, would you clarify in the synopsis that the CUPS project itself is the one who’s going to make these ‘dedicated applications/services?’ #While it really does come across that B) is the CUPS project’s intentions, I guess really the lack of actual clarification of who is suppose to be making these dedicated applications/services is what prompted my post. Best Regards, |
|
First, please note the "FUTURE" in the title of this issue - this isn't something that will happen overnight. Long-term, we do plan to drop PPD code from CUPS and rely entirely on IPP for supporting printer options, reporting status and configuration, and so forth. Support for using IPP for options, status, and configuration has been in CUPS since v1.0 (20 years ago...) Before we drop PPDs, we will be working with developers to create those printer applications (particularly Gutenprint), and will likely end up creating our own printer application (based on the existing ippserver sample code) to support existing PostScript and CUPS raster drivers. So the goal is definitely not to leave people SOL, but rather to plan for a future where we aren't limited by the capabilities of the past. |
|
@michaelrsweet, you may remember that i am a great fan of driverless printing... right now it does not appear that the existing printer tools allow creation of an IPP everywhere queue when that queue can not be discovered? Am i wrong? many companies do not put printers and laptops on the same network. lpadmin works fine but is certainly not what users expect to use. |
|
@UliWehner Currently you can manually add a queue using the "everywhere" driver in the Web Interface or using lpadmin, on macOS you can add an "IP" printer and have it do the right thing, and I think the Linux printer configuration GUIs have similar functionality. Longer term we want to add support for configuration profiles (pointing to printer(s) and/or server(s)) and LDAP. All completely transparent to the application/user. |
|
@michaelrsweet, on High Sierra with CUPS 2.2.5 this is certainly not the case. I have to choose a PPD, both in the cups webinterface as well as with the printer setup tool. Is this also a future feature for CUPS 2.3? I can use lpadmin just fine but i can not see a GUI tool that will do this on High Sierra with CUPS 2.2.5. I don't want to clog up this thread but i do not think it is possible today to manually create an IPP everywhere printer short of using lpadmin. Shoot me an email if you like |
|
On macOS, the printer needs to advertise AirPrint-specific attributes to be auto-configured from the Print & Scan preferences. Not sure why the "IPP Everywhere" model isn't showing up in the web interface, though... |
|
@michaelrsweet, that is exactly what i have been trying to say. My printers are airprint printers, this works perfectly with lpadmin, but i can not find a gui, or cups webinterface way to do this manually. Not in Mac OS X and not in OpenSuse Tumbleweed with 2.3b4. |
|
@UliWehner On macOS you can open an ipp: or ipps: URL and it will get added as AirPrint (if it is AirPrint). I filed Issue #5338 to track fixing the CUPS web interface. |
|
Our use case for RAW print queues (and is mostly the reason we use CUPS in the first place) is that we have several label printers that are printed to by a Windows application that we don't have the source to and unfortunately is pretty dumb so it can only be set to print to one printer. So we created a virtual label printer using CUPS and share that with Samba so the Windows application can print to this virtual printer, and then have all the different label printers also set up in CUPS as RAW printers, and we have a little script using tea4cups that basically forwards the incoming print job to the different label printers based on some scriptable criteria that decides which printer to send it to. It has worked for years and works very well. The Windows machine handles the driver so CUPS is just redirecting the data as it doesn't know what the print job is or care. If I'm understanding you correctly your proposal will prevent us from using CUPS in this way in the future. Am I correct about this? Thanks. |
|
@nahall Yes, in the future there might not be a way to do this directly through CUPS. But since you are using Samba you can just have a printer share that runs the tea4cups script to "print" something and let Samba manage things for you. :) |
|
@marcthe12 Printing to a file is something that can be provided at the OS/desktop layer - like the "Save as PDF" in the macOS print dialog, etc. Alternately, a printer application that stores PDF files in a directory can be used. |
My personal experience: There is a slight but crucial difference between "support IPP" and "support all functions by IPP". In our case here, i switched all our printers to driverless print. Not all of them, but most did work with ippEverywhere, but only partly: some functions are just unavailable. For example "collating" is missing with our OKI printers, which turns the IPP support to be unusable because we need this function to print from our ERP system. If i run the same printers with PPD driver, this function is available, as well as with the windows driver. Some of them (not older than 7 years ) can even be crashed by sending an IPP job, and they need a hard reset after that. Nevertheless oki have the cheek to print in their brochure "ipp support: yes". I am asking me if this is just a singular bad example for the mentioned 98% or if this is more the sad rule?? IMHO there should be something like "certified IPP support" trademark, that is only issued to the manufacturer if 100% of all functions are implemented. Or a kind of pillory where all the ignorant companies and their models are published. I agree that at the end dropping printer drivers is basically right and consequent, but i doubt your 98% number status, so i am not sure if the time has come for that action. |
|
@jschwender Look for "AirPrint", which requires that they both support IPP and their finishers via IPP. If they don't, then they've broken their AirPrint certification and they need to fix it... Anyways, that sort of situation is thankfully very rare these days. Especially for enterprise MFPs that have long development cycles, it's taken a little while for some vendors to catch up, especially those with a long history of proprietary solutions... |
|
It looks like Brother printers still require a proprietary driver to work at all. Does anyone have any contacts with them? |
|
Hi @michaelrsweet |
|
@babafall6 http://labelary.com offers a commercial service which converts ZPL to image or PDF. It's the only one I'm aware of. |
|
This issue mentions the removal of raw printing and describes two use-cases
There is another use-case, which I personally use within our company, and I like to mention this, I assume others also have this kind of workflow. We have several thousands of cross-stitch patterns that are printed when ordered. Some of these are in booklets (TwoUp), holes or staples, folded, different paper formats or special coated paper from a specific tray. These patterns are created as a pdf file. We run a script that takes in the correct printer options and creates a postscript file of it. This means we have postscript file which dictates:
The postscript files are generated once, and send to the printer with One of the advantage of this workflow, is that we don't need to process the pdf every single time through cups (saves processing time). Why would a document needs to be processed every time by cups if the source (a pdf) never changes and the result (the print) are exactly the same? The workflow is as follows: Generating a Postscript file For each document, I first change the filename of the resulting postscript file of the 'virtual file printer' (printer instance with a file descriptor) After this, I do the actual printing This command will create the Printing the actual postscript This workflow has two issues that are being depreciated.
This last point, can be fixed by using I have discussed my workflow with the printer supplier and others, but the usual advice is to use Hotfolders, but this means, files still go through cups each time, which I find unnecessary and making the workflow more error prone. If there is another workflow possible with the new versions of Cups, that generates Postscript files (with all the printer settings included), I really would like to know. |
|
Interesting approach. So for printing itself you don't need cups at all, after you created the print file. You could try raw print using netcat: |
Well, that's presumptuous. CUPS is a standardized tool to use the printer regardless of attachment. Sure, a "raw" printer, it's not "needed" in the same fashion that hammer isn't needed if you have a rock. A major global ticketing company uses the same "raw" PostScript technique with our product (as well as a similar technique with FGL). Although they do talk directly to the devices by USB vendorId/productId for some setups -- it's not used for all because the very nature of identifying a printer by IP or USB isnt as straight forward as using the print subsystem because standardized procedures aren't as common. Furthermore, without the use of CUPS, Bonjour makes this a bit trickier to support as the address is generally auto-discovered by the print subsystem, further obfuscating the printer we'd like talk to (e.g by forcing vendors to use a separate discovery service first). Fortunately for the sake of raw printing, this client uses Windows for most deployments, so this bug isn't as big of a threat, but that forces the software vendors to lay lenience towards (or against) an OS, something disappointing as a developer as we watch tech seemingly become more ubiquitous as more businesses services move to "apps" and browsers. |
|
@jschwender
Just realised today, that if I send a Postscript file to the printer without the So for my case, the 'raw' feature is not needed anymore. |
|
@rempargo |
|
Hmm, An idea crossed my head. It maybe not feasible, but can we split cupsd into 2 daemons, One can only supports ipp everywhere while another is support all functionality as an ipp server on localhost. |
|
@marcthe12 That is effectively what the plan is - Till Kamppeter has written a PostScript printer application for existing PostScript/Ghostscript/Foomatic drivers, I have written LPrint which handles the label printers, and work is underway to implement a Gutenprint printer application, all using my PAPPL printer application framework. |
|
@michaelrsweet would it be possible to use an AF_UNIX socket instead of a TCP socket? The latter raises concerns over local escalation of privilege attacks. |
|
@DemiMarie Currently there is no way to do DNS-SD discovery for domain sockets, so no. But that would be a good thing to ask for over at the OpenPrinting CUPS repository. |
|
Tracking this over in OpenPrinting CUPS. |
can you please post which issue number you filed this under instead of the general site URL? |
It seems that this issue has been moved to OpenPrinting/cups-sharing#4. |
|
@wiene Thanks for providing the link. I have added a reciprocal link to the OpenPrinting CUPS bug. |
|
Here is an excerpt from the new bug about existing printer applications:
|
|
Just to add my thoughts to this: I currently write my own custom backends for print-to-file queues (a feature lost from Classic MacOS days!). Will I have to use PAPPL to implement these in the future? |
|
@benwiggy Conceptually you could use PAPPL for this, but I believe that all of the current desktop environments support a print-to-file functionality. Providing a server that does print to file has its uses but also adds its own security issues... :/ |
|
There's no option in MacOS for a print-to-file print queue. A queue is the easiest and most useful way for automating PDF creation: just send the jobs to the printer. Is that a security risk? |
|
@benwiggy There may not be a queue, but there is the "Save as PDF" option (which can be automated through the various macOS methods) in the print dialog itself. In any case, it is possible to do a virtual printer application that prints to a folder/directory of your choosing (PAPPL or not - you can use ippeveprinter bundled with macOS to do it!) today and it'll work better than whatever you've been using for a custom backend and PPD file. |
and others
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 could migrate to standalone applications/services using the CUPS API to provide an IPP Everywhere-compatible Printer instance, and both the one-file ippserver sample code and the larger implementation in the PWG IPP Sample code repository show this is feasible, even for existing CUPS-based drivers. And as an advantage of this approach drivers like Gutenprint will no longer be shackled by the limitations of PPD files.
The text was updated successfully, but these errors were encountered: