[cups] new print driver best practices

[Michael Sweet]

Jacob,

> On Oct 9, 2015, at 5:07 PM, Jacob Marble <jacobmarble at google.com> wrote:
> 
> I would like to make some things clear before finishing the design for a
> new printer driver, which requires a custom backend.
> 
> cups-driverd and anything that lives in /usr/libexec/cups/driver has been
> deprecated completely.
> - Does the PPD keyword APAutoSetupTool replace [cups-driverd cat ppd-name]?

No, they do two different things.

> - Should APAutoSetupTool be a command-line tool with zero user interaction,
> or could it gather information from the user via a GUI before exiting?

It must be a command-line tool and must not interact with the user.

> - Is APAutoSetupTool invoked on all platforms? I ask because it's not under
> "OS X Attributes" in PPD Extensions
> <https://www.cups.org/documentation.php/doc-2.1/spec-ppd.html>.

APAutoSetupTool is only used on OS X.

("AP" is the Apple keyword prefix assigned by Adobe, and that section starts with "This OS X keyword"...)

> A backend filter is executed to (1) discover printers and (2) print. It
> sends interesting information through stderr, "back channels" and "side
> channels".
> - Is a backend also used for port monitoring, or should that be a separate
> binary placed in /usr/libexec/cups/monitor?

CUPS port monitors are intermediaries between the driver/filters and backend and are not like port monitors on Windows.  Look at the bcp and tbcp port monitors included with CUPS for an example of the function they perform.

> - Is a port monitor how printer state is indicated when a backend isn't
> running?

No. Printer state is only updated when a job is printing.

> - How is a port monitor invoked? (how often, what triggers it, what are the
> args[], etc). The backend(7) manpage is really great; can't find anything
> for port monitoring.

It is part of the filter chain.

> The PPD compiler is a nice way to generate a PPD or many PPDs with
> model-specific changes.
> - If the backend discovers a printer with device-id
> "MFG:Foo;MDL:Bar;CMD:Baz;CLS:PRINTER", is this used to find a .drv file in
> /usr/share/cups/drv/ with matching Manufacturer and Model? Are other device
> ID keys (CMD, CLS) considered at all?

CMD is often used to differentiate between two models with different PDL capabilities (i.e. PostScript SIMM in older printers).

> - Could a complete driver look like this (assume OS X and no extra
> filters)? Could the files all reside in /Library/Printers/Foo?
> /usr/libexec/cups/backend/foo
> /usr/libexec/cups/monitor/bar
> /usr/share/cups/drv/qux.drv
> /Library/Printers/Foo/.../bar

On OS X, we support PPDs in /Library/Printers/PPDs/Contents/Resources and in "printerDriver" bundles, e.g.:


    /Library/Printers/Foo.printerDriver/Contents/Info.plist
    /Library/Printers/Foo.printerDriver/Contents/MacOS/*  [filters, etc.]
    /Library/Printers/Foo.printerDriver/Contents/Resources/Profiles/*.icc
    /Library/Printers/Foo.printerDriver/Contents/Resources/PPDs/*.drv
    /Library/Printers/Foo.printerDriver/Contents/Resources/PPDs/*.ppd
    /Library/Printers/Foo.printerDriver/Contents/Resources/*.icns
    /Library/Printers/Foo.printerDriver/Contents/Resources/*.lproj/*.strings

Using the printerDriver bundle approach is generally the better approach since it allows you to code sign your driver (required in all recent versions of OS X), include any utilities/applications, and makes localization, etc. easier.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair