[cups] new print driver best practices

Jacob Marble jacobmarble at google.com
Fri Oct 9 14:07:34 PDT 2015


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]?

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

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

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?

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

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

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?

- 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

Thanks,

Jacob



More information about the cups mailing list