Non-Static Drivers - Printers with Installable Accessories

[tillkamppeter]

When a printer is set up, it gets assigned a named driver. Usually, there is one driver for each printer model or a class of drivers for each printer model.

For this driver the Printer Application fills in a driver data structure of type pappl_pr_driver_data_t with information about available resolutions, trays, paper sizes, ... when creating the printer and on every start of the Printer Application. For most, especially low-end printers this works, but for high-end printers we run into a problem: These printers often support optional accessories, like extra trays, duplexer, finishers, ... The combination of accessories actually installed would lead to different driver data on the same printer model and one cannot create a "model" for each combination of accessories, as 7 accessories would lead to 2^7 = 128 "models" for one actual printer model.

High-end printers are either PostScript printers or IPP printers:

1. IPP Printers: They work driverless and dependent on what accessories are installed the answer to the get-printer-attributes IPP request varies. I have got a second paper tray for my HP OfficeJet Pro 8730. Before I installed it, the "media-source-supported" attribute had only one item, "main", after installing it, I got "main", "alternate", and "auto". In "media-ready" I got additional entries for "alternate", ... These printer do not need a Printer Application and all works out-of-the-box for them.
2. PostScript Printers: The capabilities of PostScript printers are described by static PPD files, one per model. The PPD file describes the possible accessories and their presence with options, in the "Installable Options" group and it controls which choices for print job options are available via option conflicts/constraints. On most PostScript printers it is not possible to poll the printer to find out which accessories are installed. The user/admin is supposed to set the "Installable Options" in a printer setup tool and after that print dialogs only allow to use job option settings which are supported by the accessory configuration of the printer. Some PostScript printers allow polling for the presence of accessories, in this case the needed commands are listed in the PPD file.

The PostScript Printer Application is supposed to emulate an IPP printer behaving as in (1) as good as possible, having a PostScript printer and PPD file as of (2). Automatic setup or manual setup of the printer via "Add printer" only finds the make and model of the printer and assigns a PPD file to it. The driver setup ps_setup_driver() then parses the PPD file and fills in the driver data structure, including vendor-specific options. All this depends only on the static PPD file, not on the individual default setting configuration of the state file, so also not taking into account the accessory configuration when it is saved in one or more (invisible) vendor options as proposed in issue #91 and for creating the driver data correctly, the accessory configuration needs to be known. The driver data needs to reflect the exact configuration of the printer to produce a correct answer to a get-printer-attributes IPP request from a client.

This is because papplSystemLoadState() loads the state file line by line and when a printer header comes, it calls papplPrinterCreate() and only after that it loads the following lines with the default settings. What would be needed here is that when the end of the printer entry in the state file is reached a callback would be called. This could update the driver data depending on the default settings, for example removing trays which are no actually installed, from the media sources, removing the double-sided duplex settings if there is no duplexer, ... The callback could load the driver data with papplPrinterGetDriverData() and papplPrinterGetDriverAttributes() update it and write it back with papplPrinterSetDriverData().

So my feature request here is to have an appropriate callback function call added to the end of papplSystemLoadState().

For reference, the commit in the PostScript Printer Application with the "Installable Options" work done is here.

[michaelrsweet]

@tillkamppeter Do this initialization the first time your status callback is called - you are allowed to call the papplPrinterSetDriverData function to update the printer attributes, as needed.

[tillkamppeter]

I have now done a quick test when the status callback gets called. Unfortunately it gets only called if there is an IPP request from a client. I have stopped cups-browsed on all machines in my network now and restarted the PostScript Printer Application and done nothing else after starting it. The status callback does NOT get called. CUPS itself on the remote clients seems only to browse DNS-SD to know about remote printers to create a temporary queue on-demand for, but seems not to speak IPP as long as one does not at least open a print dialog on the client.
Could PAPPL be changed to run the status callback for each printer once after the printer is completely set up (for example in papplSystemLoadState() when it reads a </Printer> line)?

[michaelrsweet]

@tillkamppeter I think calling the status callback from papplSystemLoadState is doable.

[michaelrsweet]

[master 673a574] Call status_cb after load (Issue #107)

[tillkamppeter]

I got the "Installable Options" support for the PostScript Printer Application completely working now. With the call of the status callback after loading a printer's entry it works perfectly. Thank you very much.