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

Michael Sweet <[email protected]> Tue, 17 Jan 2023 14:27:00 -0500

Newsgroups	dev.linux.lists.printing-architecture
Message-ID	<[email protected]>

Till,

> On Jan 16, 2023, at 6:06 PM, Till Kamppeter <[email protected]> wrote:
> 
> On 16/01/2023 18:27, Michael Sweet wrote:
>>> Not like OAuth support where we decided on skipping working on its integration this year?
>> Um, I'm not aware of any such decision!  Certainly we haven't finalized things but our goal is to have IPP+OAuth prototyped this year (at least).
>> 
> 
> I meant here that we do not start GUI integration of the OAuth support of IPP this year, as important changes to make it really usable will only come somewhere later during this year.
> 
>>> - Is there actual coding work to do to achieve this?
>> PAPPL should already have everything covered, but I'll do a final pass after the 5100.7 and 5100.13 updates are final/approved.
> 
> 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.

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

>>> CPDB backend for IPP Infrastructure/Cloud printing
>>> --------------------------------------------------
>>> 
>>> Which software is the actual implementation of this standard and visible for the end user who wants to print from an application?
>> From the client side you are just printing to a different server.
> 
> So I only see it as an IPP printer, so CUPS and the CUPS CPDB backend are all I need?

Yes.

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

________________________
Michael Sweet

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