FUTURE: Remove printer driver and raw queue support.

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. This bug has not been scheduled for a specific release
milestone and this is not something we will implement immediately.  Because most printer drivers
exist outside of CUPS this change needs to be discussed publicly.

Why do we want to do this?

Raw queues used for special-use printers require custom applications that know about printer capabilities and how to produce printer-ready (document) data. Using CUPS is a convenience, but plenty of applications talk directly to printers (think Point of Sale systems)
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
Almost every printer manufactured since 2010 supports IPP/2.0 with standard file formats

Holdouts are industrial label printers and certain vertical market printers

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
PPDs and drivers are a security and distribution nightmare

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.

This looks a bit scaring without a planned date or CUPS version
when printer driver and raw queue support will be actually removed.
In https://github.com/apple/cups/issues/5269 the commit
https://github.com/apple/cups/commit/003c1790e990a836d3c66c9ef458f9057de9b674
reads (excerpt):

The "raw" model is deprecated and will not be supported in a future version of CUPS.

In https://github.com/apple/cups/issues/5270 the commit
https://github.com/apple/cups/commit/ada35e599c31cd0556a3a780a524e5bdf7dabf9e
reads (excerpt):

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
when PPD, printer driver, and raw queue support will be actually removed.

In issue #5270 you wrote that

basically all printers sold in the last 8 years support IPP and standard file formats, we should formally deprecate printer drivers in CUPS
But printers are used longer that 8 years. For example, we use three printer HP LaserJet 4350 DN, which are first sold about 2004, and we have HP LaserJet 2300, first sold about 2003. They support no IPP Everywhere (at least as I know), and there may be many other printers around that need printer drivers.

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.

@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
many thanks for your prompt reply.
"future planning" looks much less scaring ;-)
Nevertheless I wonder if printing really could work
in practice "out there" in the foreseeable future
without any driver software i.e. without any
"device dependant additional software".
I guess manufacturers will always develop new kind of devices
or new kind of device functionality which needs device dependant
additional software to get the new stuff working.
By the way:
In Feb. 2018 there was a discussion on the Gimp-print-devel
i.e. the Gutenprint devel mailing list with subject
"OSX support (Was Re: CITIZEN photo printers)"
that wandered from the subject because I wrote something about
"PPD files are declared 'deprecated' at CUPS upstream"
and a Gutenprint developer repied that for printer driver developers
the PPD APIs are all they have to work with, see
https://sourceforge.net/p/gimp-print/mailman/gimp-print-devel/thread/20180219222444.GA18161%40shaftnet.org/#msg36231072

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 know that you started Gimp-Print that is now called Gutenprint
which is why I mentioned that particular Gutenprint driver discussion
as an example why even nowadays printer driver developers may
need some help to better understand how they could make
their device dependant additional software (e.g. "drivers")
in compliance with nowadays and future CUPS.
I have a general understanding question:
Is my understanding right that future CUPS (without built-in driver support)
requires that its recipient (i.e. whereto the cupsd will sent the print jobs)
is an "IPP Everywhere-compatible Printer instance" where such
an "IPP Everywhere-compatible Printer instance" can be basically
anything where the cupsd can communicate via IPP protocol and
which accepts the standard IPP Everywhere data formats?
If my understanding is right, it would mean that any physical device
that is not IPP Everywhere compatible could be made such
an "IPP Everywhere-compatible Printer instance" by some
device dependant additional software that implements
an "ippserver wrapper" around that physical device
so that it appears to the cupsd as such an
"IPP Everywhere-compatible Printer instance".
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.

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

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

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?}.
B) CUPS is washing it’s hands of A) and someone else can create dedicated applications/services to service A).
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,
Michael

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

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

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.

I'm in a similar boat, but without the tethered design.  I run a project that hands-off raw commands to printers and we really only use CUPS to configure the raw queue so we have a way for the end-user to configure the printer while the application vendor controls the print sequences.

One of the design goals of CUPS was to eliminate the need for raw printing, and to provide a common interface and print file format to all applications so that UNIX applications and users could enjoy the same benefits as those on macOS and Microsoft Windows which likewise provide a common printing interface.

This is true for consumer printing, but for industry printing, raw is still king.  But let's talk specifics... Some drivers on Windows (such as Epson TM-series and Zebra label printers -- both widely used in the industry) accept mixed content.  They allow modern printing techniques as well as -- lightning fast -- raw commands and detects the print flavor and acts accordingly.  When I say "lightning fast", I mean by a factor of 5x speed in some cases when compared to loading the libraries necessary to do PDF rendering combined with the spool time for the graphics and shapes.  Furthermore, these printers are generally restricted by very low DPI (e.g. 180 for point-of-sales, 203 for shipping) which means the industry is often OK with a tiny chunk of text to represent a (relatively) large amount of output.
Although the announcement states several times that this "isn't happening overnight", the blog states 2020, which is 2-years and is a timeline that can really rip out the Macs and Linux machines from the industry in a timeline that many of us need to prepare for.
Some questions...

Will lpr -o raw ... and friends be removed?  We use this technique as a fallback on occasion to use RAW without specifically using the RAW driver.
Will whatever replacement to PPDs be able to support -- at a high level -- the ability to send raw commands if the driver manufacturers get on board?

Again... using specifics... CUPS bundles the Zebra ZPL and EPL drivers which leads me to believe regular driver enhancements from Zebra and friends don't make it in regularly.  Is the plan to remove these drivers or have Apple work with the driver guys at Zebra to make new ones?

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.

This is comforting for sure. :)

Today the only printers that “need” a raw printing interface are dedicated label, receipt, or logging printers, and those same printers are poorly served by CUPS because the applications using them assume they have exclusive access to the printer, send a single “page” of arbitrary length that is not known ahead of time, and/or have specific timing requirements that CUPS cannot guarantee.

I can see the problem, and access a printer through a RAW technique definitely leaves a lot of the advanced messaging that a business relies on out of the picture, but RAW access to a printer that's listed in the System Preferences (regardless of whether or not CUPS is the communication channel) is very nice from a PC support perspective.  We use this technique with some rather large clients and they like the flexibility of being able to support Mac and Linux just as well as Windows by setting up the RAW driver.  If the driver manufacturers don't meet the same timeline as CUPS, it will force the ISVs to make middleware to fill this gap by pulling comm info from the printer mapping and trying to bypass the spooler entirely.  This works well but seems like a regression.  Please demystify any false assumptions I have here and P.S. thanks for CUPS. :)

@tresf In answer to your questions:

Will lpr -o raw ... and friends be removed? We use this technique as a fallback on occasion to use RAW without specifically using the RAW driver.

Yes, the "raw" option will no longer be supported. You might be able to specify the MIME media type for a printer's "native" (legacy) PDL, e.g., application/vnd.hp-pcl for PCL, but we won't be supporting "raw" printing like we used to (forces us to make too many compromises).

Will whatever replacement to PPDs be able to support -- at a high level -- the ability to send raw commands if the driver manufacturers get on board?

IPP supports "raw" printing, meaning printing using some random vendor PDL, and that is the bare-bones minimum required for IPP/1.1 conformance. Prior to about 2009, that was pretty much all most vendors supported, which greatly limited what you could actually accomplish using just IPP and a printer.
...
All that said, it would certainly be possible to implement a raw-printing service (something you could use instead of/along side of CUPS) that just maintains queues for IP/USB printers and copies the print data directly without conversion/processing/translation. Such a service could be optimized for speed and simplicity while still providing the same sorts of convenience you get with "lp -oraw".

All that said, it would certainly be possible to implement a raw-printing service (something you could use instead of/along side of CUPS) that just maintains queues for IP/USB printers and copies the print data directly without conversion/processing/translation. Such a service could be optimized for speed and simplicity while still providing the same sorts of convenience you get with "lp -oraw".

Speaking from a business that spends most of its time with raw devices if there's a relatively simple mechanism --  via configuration, programming or driver -- that allows (e.g. a Qt-based or a Java-based) application to talk the printer, that would suffice but what I think is no immediately obvious to the consumer -- by consumer, I mean a person consuming the CUPS as an interface from a 3rd-party API perspective -- what the elimination of raw means and if it will outright kill a product benefiting from this on a Unix-style platform.
When I say "kill", I'm embellishing on the fact that we'd otherwise need mechanisms for communicating directly with serial|parallel|USB|IP-based devices quickly.  I realize CUPS really only offers a printer name in these instances, but these frameworks make the printer names iterable on Windows, Linux and MacOS which provides a direct path for raw communication.  Java provides a raw byte array as part of their permanent API and for Qt we just use the Qt APIs to fetch the printer name and then manually call cupsStartDocument  with the CUPS_FORMAT_RAW flag.
So from a C++ perspective, a replacement API should suffice, but it will require some type of negotiation and upgrade for the API calls -- of course the old API would fail to compile -- and I assume Java would be left in the dust for those applications that rely on raw printing from a Unix system.  I'm not sure how Mono/.NET would be affected as I've never used their API.
So from a developer's perspective, I still am not sure what type of options we'll have if we plan to continue using Unix for the foreseeable future.

@Michael-IDA "Common" in the original "Common UNIX Printing System" never meant "support every printer and application on the planet."
Common meant:

Using the same printing system and application/driver interfaces on multiple operating systems;
Using the same document format(s) for all printers, regardless of their actual capabilities (initially PostScript, later PDF) so that applications (and the toolkits they used) could produce pages using regular drawing functions rather than hardcoding file format support into every application;
Using the same option names for all printers, regardless of what the underlying driver/printer might call something; and
Using a common set of backends for communicating with printers so that drivers (printer-specific or generic - we've had both since day one) don't need to hardcode support into every driver.

Rather, we are saying the basically all general-purpose printers sold in the last 10 years already support what we need to provide a more efficient printing system, and that we are moving support for (at least some) driver-based printers to a separate component (a "Printer Application" or its equivalent) which can better address the needs of that "segment" - typically fine-art/photo/label printers with custom USB protocols that don't work well with the current CUPS backend architecture or with complicated configuration/presets that overwhelm print dialogs.
I think it is clear (or it should be given everything I've said and presented over the last 4 months) that enterprise printers (the kinds of printers that last 20+ years and that you can still buy supplies and parts for) will continue to be supported, and that we are still figuring out the best way to do so - PPDs are a natural fit for PostScript printers, but not the best fit for PCL. Windows (SMB) printing is also something we want to continue supporting, but again we don't want to keep doing things the same way because we have tons of issues with the variety of "solutions" in that space.
Raw printing is typically used in two spaces: custom label/report printing and Windows printing. The Windows (SMB) printing case is almost always geared towards general purpose enterprise printing which we can (and will continue to) support from CUPS in some way.  Raw label/report printing is primarily done in a closed production environment (SAP, UPS/FedEx/name-your-shipper APIs, etc.), and there I think a dedicated raw spooler is a better, faster, lighter weight solution than keeping raw support in cupsd (where it is a special case we have to check for at every turn). This custom spooler could continue to support printing via CUPS API (where it just appears to be another local IPP queue) but otherwise the jobs would be routed separately where we could pipeline things and optimize the error handling/retry logic.
Finally, we have too many "simple IFs" in CUPS already. Really, look at the code. We're at the point that making changes in one (seemingly) isolated place can cause things to break elsewhere, and we can't add a lot of new functionality without jumping through a lot of hoops and adding lots of "simple IFs".
Printing is not simple - if it were we would not have the number of problems we do, even after 20 years of making it as simple and reliable as possible.

@tresf We don't want to leave raw printing users in the cold, but how we support those printers is going to change because raw printing is fundamentally different from general-purpose printing.
A label printer can have a driver (or in the future a Printer Application), and that can be exposed via the standard OS print dialog. That driver (and the Printer Application) can also advertise the printer's native print format (EPL, ZPL, etc.) allowing an application that can produce the format to send printer-ready data. That is the model we want to see, not force users to depend on a specific application to support their printer (at which point the application is on its own).

@michaelrsweet
In my experience (I work with @tresf), the drivers for label printers in MacOS and Linux typically do not support raw printing; only raster/2d jobs. Take the ppd for a Zebra printer shared here, for example:
https://gist.github.com/JakeVdub/3cce5604cf82d0172a4c2ee267e6b677
This works well for printing PDFs from MacOS or Linux to my Zebra 2844-Z (an old label printer, but still works like a champion), but if I want to send ZPL to it, I create a separate raw queue that acts as a pass-through to the port/IP at which the printer is connected. Raw printing is much, much faster than 2d printing, since it uses the processing power of the printer, not the PC, and as such is vastly preferred for industries such as shipping/fulfillment, Point of Sales (receipts, kitchen tickets, grocery stores), printing concert/event tickets, and report (think OKIDATA - they still sell for over $300 USD) printing.
Is it the pass-through nature of raw printing and lack of a driver that makes it so different from PostScript/PDF/2d printing  in CUPS' perspective?
In my experience, raw queue support is a peripheral communication problem, but this has seemed to be relatively easy to navigate without CUPS, as long as you have a little command-line experience. The trouble is, when polling the printers in the OS, we'd like to see those peripherally connected devices as well as our laserjets and inkjets, even if the OS just sees them as a COM port.
I'd like to offer to test whatever solution you come up to for raw printing via CUPS as soon as possible to make sure we don't have a gap in functionality (alpha, beta, RC, et cetera). I've already noticed some PPDs missing from recent versions of CUPS (like the Zebra one posted above, for example), but with no solution for replacement. I hate telling someone that CUPS doesn't ship with this driver anymore, so download this one from ten years ago.
I want to be able to walk them through the process (or better yet, publish a wiki article that does the same) for both raw and PS-style printing and be certain that the most recent version of CUPS will support it.
"Raw label/report printing is primarily done in a closed production environment"
I think this is changing, too. We get a decent amount of inquiries, particularly from MacOS users, on how to print Amazon labels, which tend to be in ZPL format, from their home offices. We also have clients printing credit/debit cards on location in small environments. Even if they represent a small fraction of print jobs in the grand scheme of things, I don't think these numbers are going down anytime soon.
Again, thank you for the detailed replies.

That driver (and the Printer Application) can also advertise the printer's native print format (EPL, ZPL, etc.) allowing an application that can produce the format to send printer-ready data. That is the model we want to see, not force users to depend on a specific application to support their printer (at which point the application is on its own).

Are any steps are being taken by Apple/CUPS to warn these hardware manufacturers?  Something such as putting word out to Zebra and Epson engineers with a rough timeline?  In our experience, Zeba and Epson have a large part of the raw market, such as point-of-sales and shipping and both use raw languages that are commonly cloned by competitors such as Datamax(Honeywell), Intermec, Star, Citizen among many others.
@lite1979 and I can offer some testing resources as well once we have something ready for testing -- either a vendor driver or a "'Printer Application' or its equivalent) which can better address the needs of that 'segment'".
Even if the vendor drivers arrive in time, a lot of them will have little interest in offering drivers for hardware that's one or two model old, so this "custom spooler" will become the new norm as it's a standard setup for all hardware, not to suffer jurisdiction by driver.
And a final wish -- although one I don't expect to get granted -- is that whatever this Custom Spooler ends up looking like, that Apple makes it accessible to users without arbitrary terminal commands and web interfaces.  Raw should be a driver option on MacOS it is on Linux and Windows. :D </rant>

@tresf Apple has been in contact with all of the popular printer vendors over the last 10 years to prepare them for this. Some have implemented support for IPP and common file formats, a few have not.
As I've said repeatedly, raw print queues are going away. If there is a dedicated raw printing solution it will be separate from the usual CUPS commands (e.g. "rawprint -d queue filename" instead of "lp -d queue -o raw filename"). But the more likely solution is to allow Clients to send vendor PDL, which would look like this for a ZPL printer:
lp -d queue -o document-format=application/vnd.zebra-zpl filename

Whether we can auto-detect ZPL accurately is another matter - there is a reason we don't have ZPL matching rules in the CUPS mime.types file after 20 years... :/

So what will be the proper workflow for RIP vendors and others (such as people who use printers for T-shirts, chemical deposition, and such) who need to use the full capability of printers?  We (Gutenprint) have a fair number of users who do unconventional things like this.
Then again, if we expose DeviceN raster, we may be able to give them the tools they need.

@RobertKrawitz A Printer Application can provide support for any RIP workflow. IPP Presets, ICC-based color management, and PWG Raster support (for lower-level DeviceN color raster data) all allow for the same kinds of things we've traditionally done with printer drivers, but better since we are not forcing everything through PPDs.

I was disappointed to find that the generic text only interface has already disappeared in Ubuntu 18.04.  I'm playing with Inkscape and Inkcut to drive a CNC engraving machine.  Inkcut uses CUPS as a traditional print spooler to access the printer port used to control plotters, vinyl cutters and engravers.  These are expensive long lived machines.  It would be nice if you didn't break this traditional interface.

I was disappointed to find that the generic text only interface has already disappeared in Ubuntu 18.04

@jimthouston a bit off-topic but I wanted to help... as of 18.04 it's only been removed from the graphical wizard/dialog.  It's still available through http://localhost:631. (screenshot).
Note, Apple removed "Raw" from the macOS/OS X System Preferences a long time ago, so anyone using CUPS + Raw on Apple has been used to the localhost:631 workaround for quite some time.

Thanks for the answer.  I had already found that the localhost:631 interface let me configure the parallel port printer.  I didn't find a generic text only interface but I did find a .ppd file which then referenced a "text-only" filter which no longer exists.  I tried texttotext but it added LF characters.  Eventually I found that I could add a "o -raw" to the lpr command in inkcut.  This got things working.  With the "-o raw" option any printer description works because the filter is being bypassed.
My point in posting here was just to let you know that there are other users of the classic print spooler.
My guess is that the whole print spooler thing won't need to exist when all printers are network connected and you just need a "dating app" to match the client that wants to print with the printer.  Could this new world be achieve as a new project which doesn't have to mess  with the existing name space?

I'd like to add something in defense of the RAW. As I understand it, starting with v2.2, the only way to connect a CUPS client to a CUPS server is by specifying a RAW protocol on the client side and letting the server-side driver/whatever do the rendering. At least, this is the only way that worked for me (after days of head-scratching). This is particularly important when Chromebooks come and join the existing hard-wired infrastructure, which is a fairly common use in education.
So CUPS 2.2 made me use RAW for the first time in years, and now future plans to remove it would actually kill all my printing from guest devices. I am confused.

@esternin Raw is not the way to do it, "everywhere" is.

I'm really stressing out over this change. Perhaps I don't need to and another solution is obvious but I'm missing it.
We run point of sale systems for restaurants and retail.  While raw isn't needed for directly attached printers, as we can simply cat out to /dev/usb/lp0 or /dev/lp0, we have a situation where one station will very often need to receive receipts from all the other stations.  Think drink and food tickets.
With raw support we can use CUPS to direct the printing files as needed and not have to worry about all the complexities.  Add a bar printer? No problem, just add that CUPS queue to the software and tickets will print there via lp or lpr.
We will often have many many terminals trying to print tickets to that printer simultaneously which is why we use CUPS to spool them.
None of the printers we use support "ipp everywhere" as far as I know so once raw is gone it looks like we will have to implement spooling ourselves.
Am I missing some obvious other way of spooling to raw printers or is this something that will hopefully be developed later (before raw is gone?)?
Also, I'm confused about the PPD issue affecting raw support.  Doesn't raw printing entirely bypass  PPD's and make any issues with them irrelevant?
Thanks for any help understanding this.

@markalston No change has been made yet. This bug is here so that everyone is aware it is coming, and what the approximate timeframe is.
First, I know of at least two label/receipt manufacturers that are working on IPP solutions and one that is already shipping products (Brother).
The main issue with raw queues is that they cannot be used by ordinary applications - the application has no way to know how to prepare the print file (media size or document format). This has led to enough bug reports that we hide raw queues on macOS, for example. A secondary issue is that they work differently than regular queues, so cupsd has a bunch of code special-casing raw support. Raw queues also cannot be audited (how many pages/labels/inches have been printed) or secured unless you introduce a filter to scan the print data for malicious (or just bogus) content, which is the opposite of what raw spooling is meant to accomplish. Also, your example of adding a new printer will only work if the printer uses the same language and has the same setup/capabilities, OR you configure the application for the new printer... It's hard to be "plug and play" if you don't know anything about what you are plugging in...
Both PPDs and raw queues suffer from common problems: discovery of current printer capabilities and features, accurate printer accounting, and common semantics for applications.
As for a raw spooling solution, that is something that could be implemented on top of libcups - a simple raw spooler/print command combination program would probably take care of 99% of the needs for raw printing, including your PoS setup. We are not planning on providing this solution, but I'm happy to help anyone that wants to do so...

I'm in the same place as @markalston. We print to Zebra label printers using shipping software that sends ZPL. It goes through CUPS rather than direct to the printer because we have logic that routes the print job to a printer based on some conditions (which is better abstracted in the print server than the shipping software).
You have to understand that the industrial world is far different than the residential and office space. ZPL is used because it is very lightweight (one print job may only be a few KB) and the printer has the built-in ability to render very high quality barcodes and such by itself, without some separate software doing the rendering. The shipping software is able to simply send a ZPL text file and have the printer do the rest.
So moving to the IPP model of the residential space where the software needs to graphically format the label, then it is converted by the print server, etc, is unrealistic and it seems very unlikely that Zebra (or other label printer manufacturers) would move this direction.
It would also require changing over software to generate label images instead of ZPL, which would require getting many software vendors on board, and many of us use industrial software that isn't updated for years and years.
Also keep in mind how fast these label printers are and how fast they are expected to be. A standard Zebra model can finish printing a 4"x6" label in 1/3 of a second from the time it is issued a job. A fraction of a second delay would slow things down tremendously.
And these printers are used in huge numbers all over the world.
What I need from a print server is not printer discovery, or a common way of rendering print jobs, or accounting, or any of those things. It is to be able to give the print server a job, have it use a hook to decide which printer to send it to, put it in a spool for that destination printer and then just send the data straight through, without changing it. CUPS currently works great for that.
I'm willing to help write software to this end -- unfortunately I have not looked at CUPS internals at all but your thought about putting something on top of libcups could work. We need something like this or else I think everyone using CUPS in a non-office commercial or industrial setting will be broken on an upgrade, and I think there are a lot of us.

@nahall IPP has no requirement for the client to render or otherwise prepare the print data. It supports "raw" printing with the corresponding loss of functionality/accounting/security - that's how CUPS has supported it since v1.0. And to be clear, the goal here is NOT to prevent applications from submitting printer-ready files (in whatever format the printer accepts), but instead to remove the special casing that has been causing us grief from day one (raw queues don't work like regular print queues) and the legacy of PPD files that prevents us from (for example) reporting the real media capabilities of a printer (and this includes label/receipt printers!)
Having written the CUPS ZPL drivers I am quite familiar with its capabilities and speed. But like every other vendor PDL that mixes presentation with device control, it has a few commands that vary based on the printer or installed features - not great if you have a heterogenous fleet of printers...
Also, Zebra (in particular) ALREADY supports clients that generate bitmap images, and ALREADY prints those 4x6" bitmaps in about 1/3 second. I know this because the CUPS ZPL driver was used for many years printing shipping labels for my former business, and that on older, slower printers than the GX420d I have in my office today. With compression (implemented by every printer these days) the size of a 4x6" 203dpi label is about 12k on average - larger than a corresponding ZPL barcode/text/vector file, but without the corresponding processing needed on the printer and still small enough that the transfer time is far smaller than the print time.
What you will see in the coming years are more label printers that support IPP with both the standard raster formats used by AirPrint and IPP Everywhere as well as the traditional PDLs. The first label printers released with this capability have been the smaller desktop and mobile printers, as they are often paired with phones or tablets.

Having written the CUPS ZPL drivers I am quite familiar with its capabilities and speed. But like every other vendor PDL that mixes presentation with device control, it has a few commands that vary based on the printer or installed features - not great if you have a heterogenous fleet of printers...

I'm sorry for digging into the ZPL conversation as it's not the intent of this conversation but I wanted to make some items clear...
These commands that "vary based on the printer or installed features" are a generally rare exceptions.  ZPL (both natively supported by Zebra hardware) as well as emulated (Datamax (Honeywell) as PL-Z, Intermec as ZSim, etc) work with most standard ZPL commands.  For industrial printing, the burdons you speak of are not as severe as they're being portrayed.  Those that write and support raw languages learn to avoid these slight differences or made model-specific behavior and ZPL is one very common industrial application of raw.  Another largely adopted standard is ESC/POS.  It too suffers differences based on features but those features are minor enough for dozens of copycat printers to come to market with good, fast emulation.

ALREADY prints those 4x6" bitmaps in about 1/3 second

If you only take CUPS into consideration this statement is true.  In practice though, rendering libraries are generally added into code (e.g. PDF, HTML) which take time to load and interact with the print driver.  When multiplied times 500 labels, the benchmarks are clear that raw saves time, and thus money.
Problems that the industry run into with raw (in support of @michaelrsweet's points) are printer status (lack there of), DPI detection (rare, since most industry printers don't change this) and with certain application like in the case of card printers, there are capabilities such as laminators, duplexers that can drastically affect the commands.  ZPL and ESC/POS seem to operation quite happily in most industries without the advanced features.  In my case, I'm not speaking first-hand, but rather speaking on behalf of hundreds of companies that we service worldwide that use raw through Windows, Linux and macOS for industry printing.
P.S. I hope I'm not taking this too far off-topic, but I wanted to clarify the severity of the feature variance.

What you will see in the coming years are more label printers that support IPP with both the standard raster formats used by AirPrint and IPP Everywhere as well as the traditional PDLs. The first label printers released with this capability have been the smaller desktop and mobile printers, as they are often paired with phones or tablets.

My experience on Windows is that both Epson's ESC/POS as well as Zebra's EPL and ZPL drivers have the capability of detecting and sending the raw commands using the vendor supplied driver without any special setup.  I think the industry would be happy with similar behavior from CUPS if that's what you're describing.

@tresf Yes, the intended "destination" of this change is that you'll end up with all queues supporting standard formats in addition to any vendor-specific PDLs that are available.
The intent is to stop directly supporting "legacy" printers that need drivers or lack any kind of driver. Instead those printers will need separate applications/services that can be run on demand and/or for long periods of time that provide an IPP-compatible front-end (the "Printer Application" we keep talking about) that is optimized for the printer in question. Basically, instead of using a PPD file and multiple filter/backend executables, we are using IPP and a single executable.
In the case of label printers, this architecture also will allow the printer application to keep a single connection open to the printer, eliminating the inter-job delays we often get today with CUPS raw queues.

IPP has no requirement for the client to render or otherwise prepare the print data. It supports "raw" printing with the corresponding loss of functionality/accounting/security - that's how CUPS has supported it since v1.0. And to be clear, the goal here is NOT to prevent applications from submitting printer-ready files (in whatever format the printer accepts), but instead to remove the special casing that has been causing us grief from day one (raw queues don't work like regular print queues) and the legacy of PPD files that prevents us from (for example) reporting the real media capabilities of a printer (and this includes label/receipt printers!)

I would be completely happy to have Zebra support IPP and use that but unfortunately I have not seen plans by them to do so. I am actually in the market for some new Zebra printers and would like them to have this capability as that would make things easier for the future. Baring Zebra introducing an upgrade in the next couple of weeks I will have to buy what exists in the market, and, being an industrial printer would expect it to last around 10 years. So if CUPS won't print to the printer (currently over a port 9100 socket) then I will need to find some other solution.
If I am understanding you correctly, is the solution to create a separate program that basically simulates an IPP printer in raw mode so that CUPS can "print" to that and then it just forwards the data on to the actual endpoint printer (the Zebra printer in my case)?
We currently use tea4cups to run our script to determine which printer to send the job to. With ending raw queues would it still be possible to create a virtual CUPS printer that uses tea4cups in this manner? I imagine that the virtual printer would then need to look like an IPP printer that accepts raw print data?
Thanks for walking us through this @michaelrsweet

In practice, printers misreport their capabilities often enough that being able to override that is sometimes necessary.
Now I'm all for separating that from the core part of CUPS but the capability must be there even if it's an external/optional helper application.
Oh well. As long as there's support for passthrough to traditional lpd without prerendering, it can be made to work. (Using the lpd server feature on non-server Windows is also not uncommon.)
So. What's needed is an IPP dummy that can then feed data on to raw ports, BSD-style lpd, or whatever.
(Note to self, keep a copy of lprng sources...)

@michaelrsweet There are Print Management Systems that implement secure follow-me printing with a dedicated "virtual" CUPS queue whose URI is prepended with their backend: that sets any printspool job aside ("on hold"), and redirects the captured PDL to another (PDL compatibel) CUPS queue pointing to the printer device where the user triggers a print release ("pull-print").
In that case, the virtual CUPS queue has a static PPD attached and points to backend:file:///dev/null URI. Whereas the redirect queues are typically configured as Raw printers, since they can just consume the PDL which is already there.
How do you envision follow-me printing without static printer drivers and raw queue support?

@rijkr An IPP Everywhere conforming virtual printer application (typically the "follow me" print system, of which many already support AirPrint so the work is already done) can accept the print job, more easily in fact than the old raw queue or static printer driver method.

Was this change recently executed in macOS Catalina?  I can no longer add a raw queue through the web interface.

Set Printer Options
Set Printer Options Raw Printer
Unable to open PPD file:

Missing asterisk in column 1

@tresf it is probably Issue #5652.

If PPDs will be dropped, how will a printer be able to allow some custom settings, custom paper size etc.?

@mikhailnov Custom options and values have always been supported by IPP, and Clients can easily discover and use those options and values.

(I should note that CUPS has always used IPP to expose options that were present in PPD files...)

What does this mean for PostScript Printers that use a PPD file?

@dcpurton Long term PostScript support will go away completely. But for the foreseeable future there will likely be some level of PostScript (and PCL) support in order to support printing to long-lived "enterprise" printers (directly and via Windows servers).
As I've mentioned several times, printer applications can serve the purpose of printer drivers in a much more supportable way, and do not suffer from the limitations of PPD files or pipes. And the ippeveprinter tool bundled with CUPS 2.3 supports PostScript printers via PPD files, exposing an IPP Everywhere printer that can be used from any client.

printer applications can serve the purpose of printer drivers in a much more supportable way, and do not suffer from the limitations of PPD files or pipes

I hope I'm not out of line here, but I think the majority of users don't know what "printer applications" is or where these will reside.
For example, I've compiled Epson's latest ESC/POS driver (e.g. Point of Sale printers like TM-series used by nearly every retail organization in the world) and as far as I can tell, it's still using a .ppd file.  Is the proposition that Epson will author their own dedicated application for Unix systems?  If so, will CUPS return this printer when we iterate or will all apps need to be rewritten with some TBD non-CUPS printer API?  I guess it's hard for us to envision a world without .ppd.  Is there a real-world, active example of this so we can start rewriting our apps now?
I maintain an app that's sole purpose is to help printing to these types of printers (as well as many others) and I don't even know where to start.  Currently, we use Java's CUPS integration (which the source shows is a combination of command line tricks and parsing system files), but it's not enough, we have to write come code directly against CUPS' RSS feed to get some details that Oracle hasn't written.  If we need to talk directly to a "printer application", is there a draft interface?  Or is the expectation that they'll all still be in CUPS and that these vendors will rewrite drivers?  I'm still a bit perplexed by where these "printer applications" reside and how the average programmer will talk to them that doesn't involve app-specific calls for every manufacturer out there?

Raw label/report printing is primarily done in a closed production
environment (SAP, UPS/FedEx/name-your-shipper APIs, etc.),
and there I think a dedicated raw spooler is a better, faster,
lighter weight solution than keeping raw support in cupsd
(where it is a special case we have to check for at every turn).

You've hit the nail on the head with the types of environments that need raw queues (SAP + Zebra as a specific example) and those are the types of Linux variants often used in that situation.
What is the dedicated raw spooler available for RedHat Enterprise Linux or Oracle Enterprise Linux? Every support document I've seen from those companies only mentions CUPS + raw.

@sbonds There isn't a dedicated raw spooler being maintained at this time, however LPRNG was one such solution, and I've written up single-file spoolers for exactly this configuration in years past - it isn't a hard problem, and perhaps I will create a Github project for that.

@tresf The ippeveprinter tool is also sample code for how you could write a printer application that looks like an IPP Everywhere printer. Supporting PoS and label printers (including "raw" vendor PDL support for applications that need that) is just a matter of converting the existing CUPS filter to use PWG raster data (same cupsRaster* functions but the page data is full-bleed) and the IPP_* environment variables (instead of the command-line options), and then creating an attribute file with the supported media sizes, margins, etc.

... and even if the bulk of raw printing by paper weight happens in closed production environments, the number of devices that do occasional such jobs is huge.
 The thing just couldn't get margins right to fit on the label grid unless driven with raw PostScript. Yes, mostly Mac-using business as it happened to be... and they may only run that job once per month but it's a necessary one, and there's now a raw queue just for it.
I expect to run into this kind of thing occasionally for a couple of decades still.
As long as there's a manageable way to use this capability from outside CUPS itself (such as with LPRNG maybe) it shouldn't be a major problem, but if the support gets just dropped without a replacement solution...

LPRNG? What year is it?
At least I know it's supported on RedHat 7. Pity I don't mean RedHat Enterprise 7.  :grin:
I expected something newer, but on the other hand, for simply moving a stream of bytes from an "lp" style UNIX/Linux print queue to a raw port on a network device (the printer), there's really no need for anything complex. However, there is a need for something the enterprise Linux vendors and enterprise Linux applications (e.g. SAP) will support, so cobbling something together myself isn't really a good option.

@sbonds Indeed, what year are SAP and other vendors living in when they could be supporting modern protocols and formats that provide higher performance and better security?
There's a reason I wrote CUPS in the first place starting back in 1998 (over 20 years now!), and that was to provide something better than what existed for all kinds of printing, including labels. In 1995 I was able to drive 4" label printers at full speed through the equivalent of the CUPS raster pipeline (which I developed on top of the old System V printing system before CUPS) from PostScript label documents on an SGI 4D/20 (12.5MHz, 32-bit MIPS R2000 processor) system.

I'm a bit taken back by this statement.  Although I understand that the vendors can and should provide techniques to translate content to their native format, I'm not sure I agree with the sentiments.

The ticket industry uses FGL
The POS industry uses ESC/POS
The shipping industry uses EPL/ZPL
The impact industry uses ESC/POS and IBM/OKI Microline
... (there are many other, but these consume a large part of the market)

In each implementation, the formats are lightweight, fast, and compatible with a huge range of equipment including clones and often even in components with competing languages.
What the industry loves about these devices is they support on-device rendering on low-dpi (often thermal or carbon) medium without worrying about whether or not a 14pt font is going to suffer dithering, aliasing.  The native barcode formats are built with scanning in mind, without the worry of whether or not the barcode size is going to suffer from interpolation problems, producing bad data.
In regards to shipping, the shipping vendors are on board. They offer these formats directly in their APIs.  They're fast to fetch 500 labels for and they're fast to send to the printer.
Although I'm not a CUPS engineer qualified to argue why raw support needs to be removed (besides, why argue when the writing's on the wall 🤷♂), I do feel qualified to come to the industry's defense on why these raw formats still exist and how they are still very valuable and useful in 2019.
I can also list a bunch of limitations to this hardware...

Improper printer status (I can only assume this is a driver problem)
Lack of international font support (I can't truly understand why this is still a problem in 2019)

... but I don't find issue with the fact that they're still around.  Yes, I'm biased, but these raw languages are much easier to support over most nuances with 2D formatted vector-graphic content (e.g. PDF, HTML).

@tresf You said:

The ticket industry uses FGL
The POS industry uses ESC/POS
The shipping industry uses EPL/ZPL
The impact industry uses ESC/POS and IBM/OKI Microline
(I think you mean ESC/P for the last one)

This is true. I will note that all of these formats have numerous printer-specific commands/extensions and are resolution- and machine-specific. In short, you need to select which hardware/configuration you are using when generating the corresponding print file unless you are just printing simple ASCII text (which I'll warrant covers 95% of PoS printing, 99% if you include bar codes via fonts...)
 And keep in mind that this set of formats also includes in its legacy all of the EPSON inkjet printers (ESC/P2, ESC/R, ESC/i, etc.) - every one of them uses a different way to transfer graphics, shingling requirements, print head resolution and organization (number of jets/pins, offsets and spacing, etc.)

In each implementation, the formats are lightweight, fast, and compatible with a huge range of equipment including clones and often even in components with competing languages.

I can't agree with this statement. When you stick with the lowest-common-denominator features you can have limited compatibility between models and vendors, but I know from experience that you always end up troubleshooting rendering differences with each vendor pointing at the other when you try to get things fixed.

What the industry loves about these devices is they support on-device rendering on low-dpi (often thermal or carbon) medium without worrying about whether or not a 14pt font is going to suffer dithering, aliasing. The native barcode formats are built with scanning in mind, without the worry of whether or not the barcode size is going to suffer from interpolation problems, producing bad data.

This is a long-solved problem, provided that the rendering software is configured correctly - there are some historical misconfigurations in cups-filters, for example, that has caused problems with label printing.

I can also list a bunch of limitations to this hardware... first two that come to mind...

Improper printer status (I can only assume this is a driver problem)

Nope, the status information available from most printers of this class is non-existent.

Lack of international font support (I can't truly understand why this is still a problem in 2019)

This is why you rasterize on the client end... :/

ESC/P and the corresponding IBM/OKI extensions are complete and utter chaos

I have the least amount of experience with these however ESC/POS graphics -- albeit proprietary and suffering from too many standards -- has implementations which work on all hardware.
Even the cash drawer pulse kick-out is raw (which too suffers differences in standards) but it's not like we're talking about 2% of equipment.  We're talking about (probably) over 90% of it.

This is why you rasterize on the client end... :/

Perhaps, but is there even a standard for continuous roll paper in CUPS?  Vendors seem to just shoot for a large value and hope it fits.  This causes truncation and in some cases if you ask for the media size, some really stretched rasterization.

Also, the rasterization solutions are pretty mixed.   I'm not complaining, but rendering HTML or PDF content is extremely difficult without large helper libraries, which often are overkill when trying to send a shipping label or receipt from a web service to a printer.  Furthemore, driver support from vendors for CUPS seems to be largely a crapshoot.  Epson's requires compilation, Zebra's (AFAIK) aren't even made by Zebra and stuff like darkness and print speed end up being controlled through raw in the end anyway.
Again, I'm not try to "preach to the choir", but rather sharing grave concerns about what happens to these industries the moment CUPS drops support for raw.  I don't envision the industry changing overnight or even in several years after this change is made.  Hopefully I'm wrong.

that the rendering software is configured correctly - there are some historical misconfigurations in cups-filters, for example, that has caused problems with label printing.

Perhaps this is one of the biggest gaps.  For example, how does a small ISV explain this to Oracle (Java) or Apache (PDFBOX) to fix these things for say, a PDF?  This is just one example of course.... Some solutions like Adobe seems to "just work", but the rasterization engine they use is closed and strictly licensed (more expensive than Oracle in my experience).  These aren't necessarily CUPS' issues to solve, but until addressed, the programmers are going to find the open, shortest path first, which is often raw.

@tresf

Perhaps, but is there even a standard for continuous roll paper in CUPS? Vendors seem to just shoot for a large value and hope it fits. This causes truncation and in some cases if you ask for the media size, some really stretched rasterization.

There is indeed a standard, however it requires the client to know ahead of time how much roll it wants to use for a job (so you format the job in memory/count items in the receipt, then submit the job). In cases where you have an integrated/vertical solution (single printer connected to a single checkout device/station) there is no need for any spooler (the software just talks directly to the printer all the time, no spooling), but for setups where a printer is shared between stations then you need a spooler and need to know how long each receipt will be.

Also, the rasterization solutions are pretty mixed. I'm not complaining, but rendering HTML or PDF content is extremely difficult without large helper libraries, which often are overkill when trying to send a shipping label or receipt from a web service to a printer.

Maybe so, but that internationalization issue (Unicode) makes any worldwide solution dependent on it. It doesn't make sense to embed multi-megabyte Unicode fonts in a PoS printer.

Furthemore, driver support from vendors for CUPS seems to be largely a crapshoot. Epson's requires compilation, Zebra's (AFAIK) aren't even made by Zebra and stuff like darkness and print speed end up being controlled through raw in the end anyway since the driver doesn't expose these attributes.

The Zebra drivers bundled with CUPS were written by me, incorporating some feedback from Zebra. They do indeed support darkness, print speed, and other printer-specific features.

that the rendering software is configured correctly - there are some historical misconfigurations in cups-filters, for example, that has caused problems with label printing.

Perhaps this is one of the biggest gaps. For example, how does a small ISV explain this to Oracle (Java) or Apache (PDFBOX) to fix these things for say, a PDF? This is just one example of course.... Some solutions like Adobe seems to "just work", but the rasterization engine they use is closed and strictly licensed (more expensive than Oracle in my experience). These aren't necessarily CUPS' issues to solve, but until addressed, the programmers are going to find the open, shortest path first, which is often raw.

The simple solution is to set the rasterizer options appropriately. We even have sample code for MuPDF which is about the smallest PDF rasterizer I know of, and capable of being used as both a PDF generation and rasterization library.
(going off now to post some code that implements all of this specifically for label printers...)

We even have sample code for MuPDF which is about the smallest PDF rasterizer I know of, and capable of being used as both a PDF generation and rasterization library.

MuPDF is not always a viable solution.  Products that don't strictly adhere to AGPL ends in very high licensing from Artifex or lawsuits.  I'm not trying to minimize the value of MuPDF (it would be my first choice on Unix), but rather explain that it's not a black-and-white solution to this problem.  Even if the headers were legally viable, many apps are written in higher languages that don't have these bindings in place.  Note, the pricing is loosely based on Adobe's model (percentage of profits), but slightly cheaper, which is why they're not transparent about licensing costs.
I know we're taking this a bit off-topic from raw, but MuPDF is a slippery slope for commercial products, which is predominantly the space we're talking about.  Ideally, a solution will render all PDFs with the same rendering engine so that output is deterministic.  Raw provides this (with caveats) and without the painstaking process of trying to hunt down a PDF renderer that doesn't cost an ISV more than dozens of MSDN subscriptions.
I don't mean to allude that it's CUPS' duty to fix this problem, but I also feel strongly that minimizing the struggles isn't fair or accurate.  In the end, the developers are going to keep supporting raw, they'll just have to work much harder to establish communication with the hardware in a non-CUPS fashion.

@tresf Please see my new LPrint project, which implements a simple one-file label printer spooler that also doubles as a CUPS printer application... :) Currently just DYMO and Zebra ZPL label printer support (that's all I have at home right now), but you can send raw, PWG/Apple raster, or PNG files (like the ones UPS/FedEx/etc. provide you for shipping labels) and all of the right stuff happens. It also pipelines print jobs to avoid delays between files...

Thanks for working on this @michaelrsweet . I will have to try this out in the future. It seems like it could possibly work for us. I'm wondering if there is a way to incorporate some sort of hook system into it. Our current setup operates by:

We have a raw virtual label printer in CUPS
The DeviceURI for the label printer is "tea4cups://"
When a print job comes in to this label printer it uses tea4cups to first run a posthook command to determine which physical label printer (Zebra) to send the job to
Afterward it runs a second posthook command to execute some cleanup

We're doing it this way as our shipping software can only send all label print jobs to the same printer, but we want the jobs to go to different printers based on some conditions, and tea4cups makes it really easy to do that by giving us that hook to be able to call a script to figure that out. I imagine there are lots of people using label printers in similar ways, especially with legacy code that often drives these printers not being too flexible.
Would there be a way of doing these hooks with LPrint? Thanks.

@nahall Currently I haven't added any support for hooks, but feel free to file an issue requesting that sort of functionality and I'll look into it. Certainly routing jobs based on label/media size would be doable.

@tresf Is PDFium (from Chromium) a viable option?  It is BSD licensed and fairly feature-complete.  My biggest worry is that it is a Google project and so may not easily build for exotic platforms.  It also requires a fairly modern C++ compiler.

@tresf Is PDFium (from Chromium) a viable option?

@DemiMarie good PDF parsers are so sparse that I'm not even aware of any other C++ option that doesn't use GPL-with-classpath-exception or is purely commercial.  That said, in initial development, PDFium seems viable.  I'm not live with it yet, so my project only has proof of concept code.
As an aside, modern versions of Windows, MacOS and Linux have some PDF parsing support built in now, so for basic usage, it should be possible without a dedicated library.  For example, if using GhostScript on a command line, you will fall into the "aggregregate" clause.

An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. […]

@DemiMarie feel free to reach out to me directly at<EMAIL_ADDRESS>if needed.
@michaelrsweet sorry to go slightly off-topic here.

FYI, there's currently a discussion on Qt's development mailing list regarding a potental replacement of the deprecated CUPS API (thread starting at [1]), and the corresponding Qt bug is [2].
If anybody wants to join and provide input, that would be very welcome.
(I have only roughly followed latest developments in and around CUPS and AFAIU, printer applications are the plan to get out of this, but it's not like everything were "ready" and it would be simple to drop the use of PPD API right now without losing functionality for a multitude of devices, but please correct me if I am wrong.)
[1] https://lists.qt-project.org/pipermail/development/2020-May/039410.html
[2] https://bugreports.qt.io/browse/QTBUG-56545

The new driverless printing obviously does not care for localization. Since years, i always always take the ppd files and added the translations we need (de, fr, it, es). If you deprecate the use of drivers and ppd files, that means i cannot have properly translated human interface because my modified ppd will not be supported? That is not what i call great stride.
Basically, i completely agree on arguments for deprecating the wild prorietary protocol zoo that exists. The question is if the manufacturers will care for it: Exactly this wild growing zoo is the core concept for windows printing, and this is by damned fact the gravity center of this universe. Manufacturers of printer hardware have never shown any real effort for standardization in this environment. They see patchwork concept as a quick and dirty chance for competitive distinction.

@jschwender IPP Everywhere supports localization, and most printers these days provide localization files for their custom attributes and values that supplement the CUPS message catalogs that localize all of the standard attributes and values (i.e. most of them).
As for whether printer manufacturers will do it, they already are. More than 98% of printers today support IPP directly and work with CUPS without drivers - the holdouts are certain large-format roll printers (although they are coming around), impact (dot matrix) printers (...), and industrial label printers.

@michaelrsweet

More than 98% of printers today support IPP directly and work with CUPS without drivers

Do those 98% of printers have IPP support for all their capabilities, including staple, punch and booklet?

@rijkr Yes. It is required for IPP Everywhere and AirPrint (possibly for Mopria as well, but that is a closed spec I've never had access to). For the Enterprise MFPs you can expect that any printer introduced in the last 6-7 years will have the AirPrint logo on its box, and that tells you it supports finishers via IPP.

This movement to have driver less printing is something I and many other welcome, adapting to it will be necessary.
I maintain a virtual printer where I work, it is used for a documents archival application, the printer is one of the possible inputs for documents. On the Windows world, we have to adapt to the type 3 printer drivers, where those drivers can't use custom developed ports (something like CUPS backends) only MS supplied ports, be it WS-PRINT or legacy TCP ports, so in order to have a modern driver on Windows for a virtual printer you have to migrate to some kind of server application.
Now coming back to CUPS, reading all the comments, the future is to have an application implementing an IPP Server. Can we have an IPP over Unix sockets spec and implementation in CUPS like there is already an IPP over USB spec? Allowing IPP over Unix sockets, you can have a "printer application" that is not tied to local TCP ports and the hassle that it brings, like having to reserve a port and be careful it is not being used by another installed application. The advantages of having IPP over Unix sockets includes having local filesystem security in order to access the server and socket activation (on supported platforms like Linux with systemd) in order to start the printer application on demand.

@michaelrsweet, at least the most recent office printers i have here are HP printers, they do work properly with driverless, but not i have not seen any localization - it is all in english.

@robmv CUPS (and PAPPL, and LPrint) all use/support UNIX domain sockets, and they work pretty much like IP sockets, just using "localhost" as the hostname instead of the domain socket path. Conceptually you could encode the path in a URI (if you didn't care about standards compliance, that is), e.g.:
ipp://%2fvar%2frun%2fbar.sock/ipp/print

but that isn't the implementation choice I made 23 years ago... 🤷♂
While I understand the appeal of a domain-socket-only environment, it doesn't scale well (fine for well-known services, not so great for a random collection of third-party services since there is no domain socket service discovery protocol) so using IP sockets (even if limited to the loopback interface) on random port numbers with DNS-SD discovery is the best we can do at present.
Also, launch-on-demand with systemd has its appeal as well, but in practice you end up with a lot of system thrash that way - better to simply have the application paused in the background until something is asked of it. If you don't need the printer application, don't install it or have the application disabled until you configure a printer with it.

@jschwender It would be useful to know which version of CUPS you are using - localization using the printer's strings file was only added in CUPS 2.3.0...

@michaelrsweet

While I understand the appeal of a domain-socket-only environment, it doesn't scale well (fine for well-known services, not so great for a random collection of third-party services since there is no domain socket service discovery protocol) so using IP sockets (even if limited to the loopback interface) on random port numbers with DNS-SD discovery is the best we can do at present.

Sorry but what is wrong about not having discovery available. There are many business installations of printers where all discovery is disabled on printers and printers queues are managed centrally and installed on workstations by knowns DNS registered hostnames. The idea of having a printer application that is not discoverable and the applications installer just create the queues in CUPS without discovery y perfectly fine. What if the application crashes? the queue disappear and the user don't see it any more instead of having a persistent queue that fails with communication errors.

Also, launch-on-demand with systemd has its appeal as well, but in practice you end up with a lot of system thrash that way - better to simply have the application paused in the background until something is asked of it. If you don't need the printer application, don't install it or have the application disabled until you configure a printer with it.

I appreciate your opinion on this, but on many Linux distributions even CUPS is started on demand and it hasn't been hard problems for it. Will the future of CUPS kill the possibility of having an external backend for IPP over sockets if CUPS doesn't want to provide one?. What interest me is not having to implement any king of IPP authentication and leave the filesystem security allow or deny who can print to it directly, If CUPS is the only one that can access the socket, CUPS could be in charge of securing the access to the printer, not the printer application.

More than 98% of printers today support IPP directly and work with CUPS without drivers

I still can't even imagine CUPS without .ppd or raw support.
I know this is part of changes, but I find it troubling that engineers from Zebra, Epson, Star, Okidata aren't chiming in here.  It's sad because as a software developer we struggle to support Linux and Mac since it's such as small portion of the industry, but with this change the ISVs and end-users take the hit until the hardware manufacturers react.  Worse, this old hardware likely gets discarded (or repurposed onto a Windows machine).
My avatar is a "roll paper" because this is an industry which I work very intimately with.  I don't know too many others that can say the same yet I still don't see any stop-gaps that keep CUPS as a viable solution after this change.
Reducing this to a 2% statistic is a bit harsh.  The shipping, banking and POS industries have a very high saturation of this tech, probably close to 98% and I'm still not seeing a viable route to keep them on a CUPS platform.
I don't know whose job it is to fix that, and I'm not trying to point any fingers, but as an innovator of change, Apple is constantly making changes which break user-space and we all adjust.  I just don't see a path forward here. 🙁

@robmv CUPS (and PAPPL, and LPrint) all use/support UNIX domain sockets, and they work pretty much like IP sockets, just using "localhost" as the hostname instead of the domain socket path. Conceptually you could encode the path in a URI (if you didn't care about standards compliance, that is), e.g.:
ipp://%2fvar%2frun%2fbar.sock/ipp/print

Another option is to have something like:
ipp:unix:///var/run/fbar.sock!/ipp/print

or
ipp-unix:///var/run/fbar.sock!/ipp/print

A mix of the file: URL scheme (URIs don't need to have a hostname) and URIs pointing to resources inside Java JARs, for example jar:file:///path_to_jar/myjar.jar!/path_to_file/file.dat

@robmv If you can't discover the printer/service, how do you know you can print to it? And honestly adding domain socket addresses to IPP URIs is a non-starter: first, it will require EXTENSIVE changes to CUPS and applications using CUPS, and second you are assuming that the way to add a printer queue (assuming that there is a way to have a permanent queue on a Client system) will not change. The proper way to do a Printer Application is to advertise via DNS-SD and listen on a network port. That might just be on the loopback interface (not available outside the local machine).
As for systemd and cupsd, cupsd is a system service that provides general printing services on a wide variety of systems and for a wide variety of users. Not everyone prints, and so it makes sense to only run it when you are printing. Even there we have issues because server guys want cupsd running all the time while client guys want it run on demand...  Thus the future goal of having separate servers for each use case.
A Printer Application is a special-purpose program that you install and run to support a non-IPP printer or to provide IPP-based document services (document storage, release printing, etc.) where the real printers are either a) not directly accessible or b) non-existent. Since you are typically installing and running the program in a user session to support your printer, it makes no sense to set it up via systemd as a launch-on-demand service, as systemd is for system services running on dedicated ports/sockets and doesn't support the notion of user services (like launchd has on macOS).

@tresf See LPrint as an example of how you can continue to use CUPS (or not) with label printers. And the same can easily be done for dot-matrix printers (not that I have any to test with anymore) or any other printer you can think of.
I wrote CUPS to help people move away from applications that do raw printing. Yes, there are always situations where that is the right answer, but it has never been the focus of CUPS, even before Apple. Printing is incredibly hard, and I've done everything I can to make it easier over the years. Leaving raw print queues and PPD files in CUPS now is a dead-end and prevents Apple from actually supporting what all printers are capable of.

@michaelrsweet

@rijkr Yes. It is required for IPP Everywhere and AirPrint (possibly for Mopria as well, but that is a closed spec I've never had access to). For the Enterprise MFPs you can expect that any printer introduced in the last 6-7 years will have the AirPrint logo on its box, and that tells you it supports finishers via IPP.

In case of AirPrint, do all printer vendors use the same IANA registered IPP attributes/values/syntax to express printer capabilities and print-job semantics? For instance, can all printers that are capable of top left stapling, be instructed to do so by sending "finishings/20" (meaning staple-top-left). What about IPP Everywhere? Does it enforce a common IPP syntax for printer capabilities and print job settings?
A generic printer client can be semantically agnostic for each printer, because it just i18n displays the IPP options delivered by that printer. Just like a PPD is driving a generic print job setting GUI.
However, a higher level print management application, holding information from many printers, may need to query which printers support specific stapling or punch options to match a Print Job Ticket requirement. To make that work every printer should propagate its capabilities according to a common set of IPP/attributes/syntax.

@rijkr Yes, IPP, IPP Everywhere, and AirPrint are consistent in requiring the use of standard keyword/enum/collection values, with clear definitions of what each attribute and value means. (Unfortunately, that means that there are thousands of pages worth of IPP standards, but we work hard to make them clear, concise, and consistent and have an active standards and development community around them...)

@michaelrsweet

@jschwender It would be useful to know which version of CUPS you are using - localization using the printer's strings file was only added in CUPS 2.3.0...
The most recent cups i use is 2.3.1 on GNU Linux, with hpcups 3.20.3. The source code of hpcups has only localization for qt library interface, anything else is english only. My experience with other vendors is not better. Kyocera for example has a set of localized ppd files, so you can pick one or another, but i have to run a multilanguage environment. That was possible by simply combining all the translation strings into a single ppd, this way i was able to provide perfect localization to the UI. If ppd die, the user experience is thrown back on the level of Windows, which today is still not able to run multilangual. Leaving localization to the manufacturer will fail because they don't care for the 5% non Windows share. That is proven by the fact that localization of unix drivers is rarely available, even though for most printers have proper localization for their windows drivers.

@michaelrsweet

@robmv If you can't discover the printer/service, how do you know you can print to it?

Like everyone have been printing from decades, the network administrators know the printer hostnames, ports, protocol, etc. and they just simple register the queues on the computer. That has always been an option. Discovery solves a lot of problems for personal devices and non technical users.

And honestly adding domain socket addresses to IPP URIs is a non-starter: first, it will require EXTENSIVE changes to CUPS and applications using CUPS

That is a fair point, not wanting to implements it is a valid decision, not  one I wish, but valid. I can't contradict you in how difficult it must be because you are a maintainer and I am not, but will do on the applications using CUPS point. What matter the applications using CUPS if the URL starts with ipp:, socket:, lpd:  or something new like unix-ipp:?. They have already have been finding non common URI schemes before.
Who knows maybe after that future CUPS is released an external patch is developed, maybe that can change your mind.

and second you are assuming that the way to add a printer queue (assuming that there is a way to have a permanent queue on a Client system) will not change.

I have no problem with the procedure changing, but it will be very surprised if there isn't one. On enterprise networks there are many things that fight against discovery solutions like DNS-SD, like multiple subnets and VLANs, I still remember the IBM offices in my country where people had access to big printers on a floor dedicated to that and from where you can get big books printed in minutes, so sometimes printers aren't even in your own network segment. Just disabling discovery on the printers and use your enterprise domain automation tools (Windows Active Directory, ansible/puppet on Linux, etc) to create the queues is more manageable.

The proper way to do a Printer Application is to advertise via DNS-SD and listen on a network port. That might just be on the loopback interface (not available outside the local machine).

A network port is still accessible from different users on the same computer, and yes, there are enterprise networks that share computers for multiple users, specially when they leave their turn and forget to log off and another user logins, the first user stays logged in and the printer application is still accessible from the other session (if the application is per user session, see below), that probably should not have access to it.

As for systemd and cupsd, cupsd is a system service that provides general printing services on a wide variety of systems and for a wide variety of users. Not everyone prints, and so it makes sense to only run it when you are printing. Even there we have issues because server guys want cupsd running all the time while client guys want it run on demand... Thus the future goal of having separate servers for each use case.
A Printer Application is a special-purpose program that you install and run to support a non-IPP printer or to provide IPP-based document services (document storage, release printing, etc.) where the real printers are either a) not directly accessible or b) non-existent. Since you are typically installing and running the program in a user session to support your printer, it makes no sense to set it up via systemd as a launch-on-demand service, as systemd is for system services running on dedicated ports/sockets and doesn't support the notion of user services (like launchd has on macOS).

No, I am thinking on implementing a system service, that starts when the first user needs to print on that printer application (or start automatically all the time that is not my issue). What I wish with support for Unix sockets it to have the capability of restrict other processes to access the printer application directly (even on a loopbak device, network sockets are available to all locally connected users). If users can access the printer application directly, they will be able to skip CUPS provided features, like authentication, accounting, etc.
Note: You are wrong about systemd, systemd support user services https://wiki.archlinux.org/index.php/Systemd/User
A user service (systemd, launchd) for a printer application, for what you recommend for the future (network socket with discovery) will be awful because all locally connected users will see the printer advertised via CUPS for other connected users.

Hi @jschwender ,

The most recent cups i use is 2.3.1 on GNU Linux, with hpcups 3.20.3.

you use hpcups from HPLIP, which supports only creating of permanent print queues with specific shipped PPD - that means you are not using driverless/IPP everywhere solution at all, so you cannot see the feature which @michaelrsweet talks about.
IIUC (never tested myself, I have ENG local by default) you can see a different localization when your printer is supported by CUPS temporary queue (a queue which appears only when you need them - during print dialog - and disappears after successful printing - it needs to have a printer which supports AirPrint/IPP everywhere and it is discoverable via Avahi) or created manually with 'everywhere' printer model.
Zdenek Dohnal
RHEL/Fedora/CentOS CUPS maintainer

@zdohnal , thanks for the hint, @michaelrsweet sorry for the confusion. I automatically get additional printers with "driverless, cups-filters" in the driver description, also without working translations, so i thought that was the same. Got it! Tried it again by installing a "everywhere" driver and noticed that the missing translation are just caused by missing translation strings in CUPS source code. All right, so for my language i started tackling this.

@michaelrsweet, Can you clarify will this effect "printing" to a file i.e. cups-pdf for example

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

As for whether printer manufacturers will do it, they already are. More than 98% of printers today support IPP directly and work with CUPS without drivers -
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
I have install cups and add my printer Toshiba B-EX4T1-T. I can print pdf file in command line
lp -d myprintername test.pdf
But when I try with a zpl file I get text on my label.
Is it a way do print zpl file with my Toshiba by setting my printer with an appropriate drive (that I don't know) or I must find a zebra printer to achieve this.
Thank you for you help

@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

dedicated label, receipt, or logging printers
point a local CUPS print queue to a remote (shared) CUPS print queue.

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:

Which paper format
Which Tray
Which MediaType (plain, heavy-2, etc)
LongEdge vs ShortEdge
And so on....
We always keep the same format/type of paper in the same trays.

The postscript files are generated once, and send to the printer with -o raw when patterns are ordered. No user interface in any print menu is required, so this workflow is very reliable. We need to run the script for new patterns, and once in ±5 years, we have to run the script for all documents for a new printer.
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
This is done once for each pdf document
For each document, I first change the filename of the resulting postscript file of the 'virtual file printer' (printer instance with a file descriptor)
lpadmin -p Canon_IPC650_PS_to_file -E -v file:'/Some/Path/some-file-01.ps' -m 'Library/Printers/PPDs/Contents/Resources/Canon_IPC650.ppd'

After this, I do the actual printing
lp -d Canon_IPC650_PS_to_file ./some-file-01.pdf -o InputSlot="Tray3" -o orientation-requested="4" " -o EFPrintSize="TabloidExtra"

This command will create the /Some/Path/some-file-01.ps
Printing the actual postscript
We use the -o raw to bypass any cups filter and print the file directly to the printer
lp -o raw /Some/Path/some-file-01.ps

This workflow has two issues that are being depreciated.

The option to make file descriptor with lpadmin will be depreciated, from what I understood because of security issues.
Raw printing with lp -o raw will also be removed.

This last point, can be fixed by using copy /b file.prn \\Server\PrintQueu on Windows machines, but I do not have an alternative on macOs, any suggestions will be appreciated.
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:
cat filename | netcat -h hostname -p 9100
see http://macappstore.org/netcat/
We have a slightly other approach to avoid error prone user interaction. We save plain pdf and script the printing with all options of n-up and duplex and so on. This has the advantage that it is not depending on the end device, which your solution is. It still involves some processing in the cups server, but this is not much, as pdf is already the discription language the printer gets delivered.

@jschwender
Your netcat approach to send Postscript files to the printer is not the right solutions in my case:

netcat does not seem to be installed on macOS, not a real problem, I just did brew install netcat, but I just like to have the least possible dependacies.
With netcat you can only send it to a specific IP address and port, you can't select the instance/queue (print, direct, hold, etc...)
It does not seem reliable, I tried a few times, sometimes it works, sometimes not, cat SomeFile.ps | netcat <IP_ADDRESS> 9100 and I have to type CTRL-C to finalize the stream the  command, so not scriptable. (Also I think it crashed port 9100 on the Fiery server sometimes).

Just realised today, that if I send a Postscript file to the printer without the -o raw option the file is also printed exactly the way I want it. Seems like a habit of mine that is not needed anymore. When printing Postscript of PCL files before (before IPP?) without this option, the actual text representation of the Postscript commands in the file were printed, that resulted in a lot wasted papers. This does not seem the case anymore.
So for my case, the 'raw' feature is not needed anymore.

@rempargo
if that works for you with PS, and you are concerned about processing resources, you may try using PDF instead, as this is the "native" format for CUPS processing. If you give CUPS a PS it may convert it to PDF and send it to the printer, if you give it a PDF it just adds control commands to the pdf and sends it to the printer. BTW, netcat has a timeout option (-w ) which can be used in scripts. To my knowledge that is the least resource consuming way of printing as it is really pure tcp file transport, nothing else. If you do that, your file should have all job control information in it (PCL), it controls everything the printer can do, so there is no need to select a specific queue on the target. I just say it is possible, but i would clearly recommend using cups if it works for you.

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.

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.

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

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

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

Tracking this over in OpenPrinting CUPS.

can you please post which issue number you filed this under instead of the general site URL?

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

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

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:

hp-printer-app: PAPPL-based PCL printer application based on the CUPS rastertohp driver.
LPrint: Label printer application (soon to be PAPPL-based), currently supporting Zebra and Dymo label printers with plans to support more, based on the CUPS rastertolabel driver. "Raw" printing is supported as well if you have an application that produces the native print data format.
ps-printer-app: PAPPL-based PostScript printer application that supports all PostScript printers via PPDs and includes all of the Foomatic and HPLIP drivers.
Gutenprint: A PAPPL-based printer application for all Gutenprint printer drivers.

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.

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