Deprecate printer drivers

[michaelrsweet]

Now that basically all printers sold in the last 8 years support IPP and standard file formats, we should formally deprecate printer drivers in CUPS.

[michaelrsweet]

[master ada35e5] Deprecate printer drivers (Issue #5270)

Right now we just display a warning message when lpadmin is run with anything other than "everywhere".

[gotchoices]

What should those of us do who use printers older than 8 years? On a similar subject, I just discovered my SysV interface script is no longer supported and am looking for a work-around. Is there an alternate way to make your own filter/driver now?

[michaelrsweet]

@gotchoices Please see the discussion in issue #5271 for how older printers will be supported.

WRT interface scripts, you'll need to provide a PPD file that specifies your interface script in the cupsFilter lines - you can copy an existing PPD file and strip out most of the options, just remember to leave at least one paper size (with PageSize, PageRegion, ImageableArea, and PaperDimension) in the PPD file so that it passes the cupstestppd program's checks.

[gotchoices]

Sorry, I may not be conversant enough on the terminology to ask the right question, but I'm still confused.

In the "Printer Driver Basics" section of the docs: https://www.cups.org/doc/postscript-driver.html it says a driver consists of a PPD file, and possibly filters and so forth. Yet in your answer, you tell me I should use a PPD file to correctly deal with the loss of SysV interface scripts. Am I correct that with the deprecation of "drivers" there will be no more PPD files in cups? If so, it sounds like I will have no more options for implementing custom filters.

My particular application is 3.5"x1" mailing labels on tractor feed stock. The driver's job is to:

• Ignore any kind of file input other than text (so an accidental PDF file doesn't trash my label stock)
• Set the (Epson) printer to have a form length of 6 lines (So any FF won't skip unused labels).
• Pad/trim the incoming data to 6 line chunks so it will stay aligned with the labels.

With SysV interface scripts, this was easily implemented in a brief shell script filter. When re-implementing it, I would like to be able to do something that won't just be rendered obsolete again by further deprecations. How would this type of use be supported in the future without the ability to use a custom filter?

[michaelrsweet]

@gotchoices Your interface script becomes CUPS filter. (Well, it was anyways, under the covers... :)

So for now (until printer driver support is removed), you just need to have a minimal PPD file with a cupsFilter line pointing to your interface script, something like this:

*PPD-Adobe: "4.3"
*FormatVersion: "4.3"
*FileVersion: "1.0"
*LanguageVersion: English
*LanguageEncoding: ISOLatin1
*PCFileName: "tractor.ppd"
*Product: "(Text Printer)"
*Manufacturer: "Text"
*ModelName: "Printer"
*NickName: "Text Printer"
*ShortNickName: "Text Printer"
*PSVersion: "(none) 0"
*cupsFilter: "text/plain 0 /path/to/your/interface/script"
*OpenUI *PageSize/Media Size: PickOne
*OrderDependency: 10 AnySetup *PageSize
*DefaultPageSize: 3.5x1
*PageSize 3.5x1: ""
*CloseUI: *PageSize
*OpenUI *PageRegion/Media Size: PickOne
*OrderDependency: 10 AnySetup *PageRegion
*DefaultPageRegion: 3.5x1
*PageRegion 3.5x1: ""
*CloseUI: *PageRegion
*DefaultImageableArea: 3.5x1
*ImageableArea 3.5x1: "0 0 252 72"
*DefaultPaperDimension: 3.5x1
*PaperDimension 3.5x1: "252 72"

As for the future, this sort of queue won't be supported and you'll need a "printer application" that can handle IPP requests. By then I expect there will be a basic dot matrix application that supports plain text printing (in addition to raster) that you'll be able to use...

[apizz]

Sorry for digging up an old issue...

@michaelrsweet I'm working on a presentation involving a script that I'd written to programmatically install printers via IPP: https://gist.github.com/apizz/5ed7a944d8b17f28ddc53a017e99cd35

Effectively what the script does is use the ipp2ppd tool to convert the received printer capabilities into a PPD file which is then used to install the printer with lpadmin.

What I'm not 100% clear on is how the tools and methods I'm utilizing relates to the statement in the CUPS man page and this issue:

CUPS printer drivers, backends, and PPD files are deprecated and will no longer be supported in a future feature release of CUPS.  Printers that do not support IPP can be supported using applications such as ippeveprinter(1).

I'm not sure if and how this affects the method by which I've been installing printers and want to make any necessary changes to ensure future macOS support.

At the end of the day, as Mac administrator I want to ensure I have a tool which allows me to provide users a way to install printers with our desired settings (this includes printer name & location) without needing to have users do this themselves manually.

[michaelrsweet]

@apizz You are correct that PPDs are going away at some point in the future. As I no longer work at Apple I can't say when or if that will happen for macOS... That said, for AirPrint queues you can (today) switch to pushing AirPrint configuration profiles to the client machines (the same ones you'd use for iOS/iPadOS clients) - this effectively does the same thing your script does today, while presumably being somewhat future-proof for the hypothetical day when macOS stops supporting PPD files.

For specific enterprise printing support questions like this, I suggest you contact Apple directly since the Apple CUPS repository doesn't get much attention these days...