Re: [Printing-architecture] Google Summer of Code 2023 - Project ideas page for the Linux Foundation online

On 17/01/2023 16:27, Michael Sweet wrote:
>>
>> Would other parts like CUPS or cups-filters need to get updated.
> 
> There is a new (OPTIONAL) "job-triggers-supported" attribute that can be used by a Printer to suggest presets based on selections, e.g., pick a photo media triggers using the photo preset.
> 

OK, on an implementation of creating presets from within a Printer 
Application (or PAPPL) I would then allow the user also to set a trigger 
via an appropriate UI in the web interface.

In CPDB (the CUPS backend) I will add support to parse the 
"job-presets-supported" attribute of the printer to let it add an option 
to select a preset to the print dialog and if the use selects a preset, 
the CUPS backend will send this preset's settings as job attributes to 
the CUPS queue. This is how I understood to use presets following

https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20221027.pdf

> There is also the new (OPTIONAL) "client-info" attribute to provide Client-side metadata (like OS, application, etc.) - that one will need some privacy controls for users to "opt in".
>

Does this allow a client app to tell the printer that the job comes from 
this app? So that if it is Darktable for example that the printer prints 
in photo mode (sets print-content-optimize=photo)?

>>>> CPDB backend for IPP Infrastructure/Cloud printing
>>>> --------------------------------------------------
>>>>
>>
>> So I only see it as an IPP printer, so CUPS and the CUPS CPDB backend are all I need?
> 
> Yes.
>

OK, so nothing from the client side needed here, project idea removed.

>> ...
>>> Honestly I don't have a good feel for how/whether this should be implemented and added to PAPPL, and the only printer application that really needs this functionality is Gutenprint.  Probably better to focus on getting Gutenprint ported and supporting its presets, then we can look at how those presets will work with the existing PAPPL.
>>
>> I think this project is not only for Gutenprint to benefit from. Any Printer Application with at least some vendor options benefits, especially the PostScript Printer Application. Typical print dialogs cannot access the vendor options of any PAPPL Printer Application. If the user can assign presets to a name which is accessible via a standard IPP option, they could make use of the vendor options more easily.
> 
> There are few PPD options that don't have a corresponding IPP attribute, and IPP presets don't get around the Client needing to know how to send arbitrary IPP attributes/values when a preset is chosen.
>

For example a PPD file has the option "PrintDirection" with the 2 
choices "uni-directional" and "bi-directional". We assume higher quality 
by the former and higher speed by the latter choice.

The PostScript Printer Application creates a vendor option from that, 
named "print-direction" with choices "uni-directional" and 
"bi-directional". In the current version the user can set a default for 
this option by the web interface, under "Printing Defaults".

Now let us assume that PAPPL allows users to create presets via a new 
web interface page, or even automatically creates presets in some way. 
We also assume that we have a newer PAPPL version supporting the 
"job-presets-supported" printer IPP attribute and by this tells which 
presets it has readily available. The attribute will look like this:

     job-presets-supported={
       preset-name='draft'
       preset-category='print-quality'
       printer-resolution=300dpi,
       print-direction='bi-directional'
     },{
       preset-name='normal'
       preset-category='print-quality'
       printer-resolution=600dpi,
       print-direction='bi-directional'
     },{
       preset-name='high'
       preset-category='print-quality'
       printer-resolution=1200dpi,
       print-direction='uni-directional'
     }

Once, due to the preset-category being "print-quality" it changes the 
"print-quality" attribute, instead of having the 3 standard choices, it 
gets the choices defined by the presets and the printer is supposed to 
execute the print-quality job attribute by setting the other job 
attributes as described by the appropriate preset. Am I right?

Now let as assume we have the same entries in "job-presets-supported" 
but their preset-category is NOT "print-quality" but for example 
"feature" instead.

In this case a client would need to add an option to the print dialog 
named "Presets" and offering the choices "none", "draft", "normal", and 
"high", and if the user sets this to "high", the client should add the 
job attributes printer-resolution=1200dpi and 
print-direction='uni-directional' to the job. Am I right? Has this also 
to work this way despite "print-direction" is not a standard IPP 
attribute name (it is created by the PostScript Printer Application, 
derived from the PrintDirection option of the PPD)?

Implementation of the above would be done in the CPDB CUPS backend, so 
that the actual print dialogs do not need to care of this.

    Till