PAPPL-based Printer Applications: Option setting presets via web interface #314
Conversation
There was a problem hiding this comment.
OK, I started reviewing this but stopped very early.
If we add preset support to PAPPL, it MUST be based on IPP presets - "job-presets-supported" and "job-triggers-supported" in the current PWG 5100.13 specification.
This means that the preset will specify a name ("preset-name" member attribute), a category ("preset-category" member attribute, which I'd implement as an enum for the API), and any Job Template attributes associated with the preset. A trigger is then associated with a named preset and one or more Job Template attributes that cause the preset to be chosen automatically.
The current PR does not implement IPP presets. I'm not exactly sure what kind of presets are implemented, because the preset data looks like a copy of the printer driver data (to control defaults and supported values).
From a coding standpoint, the proliferation of resources will not scale well and is unnecessary. Ideally presets should be part of the printer driver data structure so that a driver can export its standard presets (like it does for defaults and capabilities) with the load and save callbacks handling the site/user-specific presets. There are also a number of coding style and exposure of private details in public headers that would need to be resolved...
| @@ -103,6 +103,10 @@ typedef struct _pappl_subscription_s pappl_subscription_t; | |||
| // Subscription object | |||
| typedef struct _pappl_system_s pappl_system_t; | |||
| // System object | |||
| typedef struct pappl_pr_preset_data_s pappl_pr_preset_data_t; | |||
There was a problem hiding this comment.
Unless needed outside printer.h, put it there...
| // This function adds the preset to the printer's preset array. | ||
| // | ||
|
|
||
| bool papplPrinterAddPresetCreate(pappl_printer_t *printer, pappl_pr_preset_data_t *preset) |
There was a problem hiding this comment.
OK, so naming is a bit confusing here. I suggest simply "papplPrinterAddPreset".
| printer->presets = cupsArrayNew(NULL, NULL, NULL, 0, NULL, NULL); | ||
| cupsArrayAdd(printer->presets, preset); | ||
|
|
||
| // Create resource data and set up routes |
There was a problem hiding this comment.
I'm not keen on presets creating resources; rather there should be a single resource for managing them with the preset name being passed as a query parameter and/or form data.
|
|
||
| // Add preset to printer's array | ||
| if (!printer->presets) | ||
| printer->presets = cupsArrayNew(NULL, NULL, NULL, 0, NULL, NULL); |
There was a problem hiding this comment.
Probably want the CUPS array to manage copying and freeing the preset data...
Generally, Printer Applications as emulation of driverless IPP printers only support standard IPP job attributes as user-settable options: media size/type/source, duplex, printer-resolution, print-quality, print-content-optimize, … but some drivers, like for example Gutenprint or also PostScript printers, have many options to fine-tune the printout and those cannot get individually mapped to IPP options so that the user can control them in a print dialog. Also many print dialogs, especially of phones, are limited to standard IPP attributes.
So what we want to add is to have a preset functionality in PAPPL.
I have developed code in PAPPL to introduce preset support, which involves predefined templates for printing defaults. These presets are included in the job-presets-supported attribute of client->response.
In /pappl/printer-webif.c, I created APIs for creating, editing, copying, and deleting presets.
_papplPrinterPreset(): This function shows the homepage of the presets, allowing users to create, edit, copy, and delete presets.
_papplPrinterPresetCreate(): This function displays the web page for creating presets.
_papplPrinterPresetEdit(): This function displays the web page for editing presets.
_papplPrinterPresetCopy(): This function shows the web page for copying presets.
_papplPrinterPresetDelete(): This function displays the web page to delete a particular preset.
In /pappl/system-loadsave.c, I created an API to save presets in a file (the file is stored in /var/spool/legacy-printer-app/name_of_the_file_for_particular_preset).
papplSystemSavePreset(): This API is used to store presets in files, with each printer having a unique preset file.
In /pappl/printer.h, I created the structure of a preset represented by pappl_pr_preset_data_s, which includes fields such as:
Name: A unique name given to the preset.
Id: A unique ID assigned to the preset.
Static attributes like pappl_color_mode_t color_supported: Each static attribute has a boolean field representing whether the option is selected in the preset on the web interface or not.
After that, I wrote the code to store vendor attributes.
In /pappl/printer.c:
papplPresetAdd(): This function fetches presets from the file (stored in /var/spool/legacy-printer-app/file_name.txt).
_papplSystemAddPreset(): This function adds the preset to the running printer thread.
papplPresetDelete(): This function removes the preset element from the printer's presets array.
_papplPresetDelete(): This function removes all memory and resources associated with a particular preset.
In /pappl/printer-driver.c, I wrote the code to initialize preset fields when needed, such as during operations like edit, copy, and creation of the preset.
papplPrinterAddPresetCreate(): This function adds a particular preset to the printer thread.
papplSetPresetVendor(): This function sets vendor attributes in the preset object.
papplSetPresetFromDriver(): This function sets driver attributes in the preset object.
Please let me know what further changes I will need to make.
Thank you!