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

Michael Sweet <[email protected]> Wed, 18 Jan 2023 12:02:13 -0500
Newsgroups	dev.linux.lists.printing-architecture
Message-ID	<[email protected]>
Till,

On Jan 17, 2023, at 5:49 PM, Till Kamppeter <[email protected]> wrote:
> 
> 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.

I don't know whether supporting triggers is necessary 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

Current version:

	https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20230116.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)?

No, the point of "client-info" is to allow a Client to identity the software components being used for printing.  It is ABSOLUTELY NOT for tailoring behavior to a particular client or application, as that way lies madness.

The specific uses of "client-info" are Job Accounting and troubleshooting (i.e. knowing that LibreOffice is the application producing the PDF file you are trying to print, or knowing that a particular version of ChromeOS isn't working, etc.)

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

Possibly, yes.  Of course, the class of printer offering this option (dot matrix) doesn't exactly offer much in the way of quality or speed... :)

> 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'
>    }

Current PAPPL supports it, you just need to pass the values in the IPP attributes in the papplPrinterSetDriverData call.

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

Not exactly.

Presets normally show up as a list of choices - the PWG 5100.13 update adds an optional category that allows UI designers to group those presets (possibly as a separate list under the "print quality" UI) but it shouldn't replace the existing print-quality UI.

One possible implementation choice would be to show print-quality presets as the "easy" UI and any print quality attributes as the "expert" UI.  The new "print-processing-attributes-supported" attribute is actually designed to facilitate this so that a Client can easily determine which Job Template attributes contribute to "print quality" (which really isn't just one control with "draft", "normal", and "high").

So please just think of presets as a way to expose common/logical combinations of attributes and values for regular users (the "easy" UI) and not as a wholesale replacement of those attributes.

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

That is one potential implementation, yes.

________________________
Michael Sweet
signature.asc (application/pgp-signature, 833 B)