Google Summer of Code 2023 - Project ideas page for the Linux Foundation online

Google Summer of Code 2023 - Project ideas page for the Linux Foundation online

[Till Kamppeter]

Hi,

the Linux Foundation will apply again as mentoring organization in this 
year's Google Summer of Code.

Note that GSoC 2023 will have a slight difference against last year. Now 
contributors are eligible either when they are newcomers in free 
software OR they are students. This gives more people the chance to do a 
Google Summer of Code project.

All the rest is as last year, especially choice between 2 project sizes 
and flexibility with the end of the coding period.

On January, 2023 the application period for mentoring organizations for 
the Google Summer of Code 2023 will start.

To be successful, we need a rich project idea list so that we will get 
selected by Google.

I have set up a page for project ideas for the Linux Foundation's 
participation in the Google Summer of Code 2023:

https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023

Please add your ideas to the sub-page of your work group. Also remove 
project ideas which are already done in one of the previous years or not 
needed any more and make sure that all contact info is up-to-date and 
all links are working.

Make sure to not talk about "students", but about "contributors" 
instead. I have, at least partially, taken care of this when I have 
copied your sub-group pages from last year.

Also make sure to remove the "**To be updated**" phrase after having 
updated your project ideas.

If you have problems mail me with your project ideas and other editing 
wishes.

The ideas list is in the Linux Foundation Wiki. If you want to edit and 
did not have the edit rights already from previous years, please tell me 
and I give you edit rights. I need your Linux Foundation user name for 
that and the e-mail address associated with this account for this.

Please also take into account that the deadline for our application as 
mentoring organization is Feb 7 and after that Google will evaluate the 
applications. So have your ideas (at least most of them, ideas can be 
posted up to the contributor application deadline) in by then to raise 
our chances to get accepted.

Please also tell us if you do not want to participate any more with your 
workgroup, so that we can remove your sub-page.

    Till

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

[Till Kamppeter]

Hi,

the Linux Foundation will apply again as mentoring organization in this 
year's Google Summer of Code.

Note that GSoC 2023 will have a slight difference against last year. Now 
contributors are eligible either when they are newcomers in free 
software OR they are students. This gives more people the chance to do a 
Google Summer of Code project.

All the rest is as last year, especially choice between 2 project sizes 
and flexibility with the end of the coding period.

On January, 2023 the application period for mentoring organizations for 
the Google Summer of Code 2023 will start.

To be successful, we need a rich project idea list so that we will get 
selected by Google.

I have set up a page for project ideas for the Linux Foundation's 
participation in the Google Summer of Code 2023:

https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023

Please add your ideas to the sub-page of your work group. Also remove 
project ideas which are already done in one of the previous years or not 
needed any more and make sure that all contact info is up-to-date and 
all links are working.

Make sure to not talk about "students", but about "contributors" 
instead. I have, at least partially, taken care of this when I have 
copied your sub-group pages from last year.

Also make sure to remove the "**To be updated**" phrase after having 
updated your project ideas.

If you have problems mail me with your project ideas and other editing 
wishes.

The ideas list is in the Linux Foundation Wiki. If you want to edit and 
did not have the edit rights already from previous years, please tell me 
and I give you edit rights. I need your Linux Foundation user name for 
that and the e-mail address associated with this account for this.

Please also take into account that the deadline for our application as 
mentoring organization is Feb 7 and after that Google will evaluate the 
applications. So have your ideas (at least most of them, ideas can be 
posted up to the contributor application deadline) in by then to raise 
our chances to get accepted.

Please also tell us if you do not want to participate any more with your 
workgroup, so that we can remove your sub-page.

    Till

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

[Ian Rogers]

On Mon, Jan 16, 2023 at 6:17 AM Till Kamppeter <till.kamppeter@gmail.com> wrote:
>
> Hi,
>
> the Linux Foundation will apply again as mentoring organization in this
> year's Google Summer of Code.
>
> Note that GSoC 2023 will have a slight difference against last year. Now
> contributors are eligible either when they are newcomers in free
> software OR they are students. This gives more people the chance to do a
> Google Summer of Code project.

Hi Till,

This is great news! Could you clarify the "newcomers in free software"
a bit. Is it the same as last year? Last year we had somebody working
in a closed source environment who applied because they had only a few
years experience and had never sent patches to LKML. We also had
somebody working for a tech giant but in a managerial role, who wanted
to work on some open source software. Beside the challenge of trying
to fit open source work in with a day job, we decided that the
candidates didn't fit the idea of newcomer and so weren't eligible for
the GSoC funding. We offered to help them outside of GSoC but none
accepted that.

Thanks,
Ian

> All the rest is as last year, especially choice between 2 project sizes
> and flexibility with the end of the coding period.
>
> On January, 2023 the application period for mentoring organizations for
> the Google Summer of Code 2023 will start.
>
> To be successful, we need a rich project idea list so that we will get
> selected by Google.
>
> I have set up a page for project ideas for the Linux Foundation's
> participation in the Google Summer of Code 2023:
>
> https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023
>
> Please add your ideas to the sub-page of your work group. Also remove
> project ideas which are already done in one of the previous years or not
> needed any more and make sure that all contact info is up-to-date and
> all links are working.
>
> Make sure to not talk about "students", but about "contributors"
> instead. I have, at least partially, taken care of this when I have
> copied your sub-group pages from last year.
>
> Also make sure to remove the "**To be updated**" phrase after having
> updated your project ideas.
>
> If you have problems mail me with your project ideas and other editing
> wishes.
>
> The ideas list is in the Linux Foundation Wiki. If you want to edit and
> did not have the edit rights already from previous years, please tell me
> and I give you edit rights. I need your Linux Foundation user name for
> that and the e-mail address associated with this account for this.
>
> Please also take into account that the deadline for our application as
> mentoring organization is Feb 7 and after that Google will evaluate the
> applications. So have your ideas (at least most of them, ideas can be
> posted up to the contributor application deadline) in by then to raise
> our chances to get accepted.
>
> Please also tell us if you do not want to participate any more with your
> workgroup, so that we can remove your sub-page.
>
>     Till

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

[Till Kamppeter]

On 16/01/2023 14:28, Ian Rogers wrote:
> Hi Till,
> 
> This is great news! Could you clarify the "newcomers in free software"
> a bit. Is it the same as last year? Last year we had somebody working
> in a closed source environment who applied because they had only a few
> years experience and had never sent patches to LKML. We also had
> somebody working for a tech giant but in a managerial role, who wanted
> to work on some open source software. Beside the challenge of trying
> to fit open source work in with a day job, we decided that the
> candidates didn't fit the idea of newcomer and so weren't eligible for
> the GSoC funding. We offered to help them outside of GSoC but none
> accepted that.
> 
> Thanks,
> Ian

"Newcomer" means newcomer in free software coding not newcomer in IT in 
general, so people who have only worked in closed-source before or 
people who were only managing in open-source but not coding are 
eligible. I assume, but do not know, that Googlers will google for free 
software coding activity (e. g. commits in project repositories) to 
determine whether a contributor is eligible.

There is also a rule that one contributor can be GSoC contributor a 
maximum of 2 times, but I do not know whether this is also valid for 
newcomers, as with the first participation you got already free software 
experience and a certain commit history. Perhaps a 1-year experience is 
still tolerated.

So your last year's candidates should be eligible.

    Till

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

[Till Kamppeter]

On 16/01/2023 14:28, Ian Rogers wrote:
> Hi Till,
> 
> This is great news! Could you clarify the "newcomers in free software"
> a bit. Is it the same as last year? Last year we had somebody working
> in a closed source environment who applied because they had only a few
> years experience and had never sent patches to LKML. We also had
> somebody working for a tech giant but in a managerial role, who wanted
> to work on some open source software. Beside the challenge of trying
> to fit open source work in with a day job, we decided that the
> candidates didn't fit the idea of newcomer and so weren't eligible for
> the GSoC funding. We offered to help them outside of GSoC but none
> accepted that.
> 
> Thanks,
> Ian

"Newcomer" means newcomer in free software coding not newcomer in IT in 
general, so people who have only worked in closed-source before or 
people who were only managing in open-source but not coding are 
eligible. I assume, but do not know, that Googlers will google for free 
software coding activity (e. g. commits in project repositories) to 
determine whether a contributor is eligible.

There is also a rule that one contributor can be GSoC contributor a 
maximum of 2 times, but I do not know whether this is also valid for 
newcomers, as with the first participation you got already free software 
experience and a certain commit history. Perhaps a 1-year experience is 
still tolerated.

So your last year's candidates should be eligible.

    Till

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

[Till Kamppeter]

On 16/01/2023 16:17, Michael Sweet wrote:
> Till,
> 
> FWIW, some of the PAPPL project ideas aren't a good fit for GSoC, particularly the IPP Everywhere 2.0 stuff (still in flux, and something I am already working on) and presets.  The scan stuff is "nice to have" but we are still a long ways away from having anything that can be merged and supported.
> 

OpenPrinting project ideas on

https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects

Michael,

I was also in doubt about some ideas when I tried to create a 
description for them:

Update of OpenPrinting software to IPP Everywhere 2.0
-----------------------------------------------------

- What are the exact differences between 1.1 and 2.0? Is it written 
somewhere to easily check?
- Is 2.0 stable and complete enough for working towards it and is it 
also no subject of a quick replacement (by 2.1?)? Not like OAuth support 
where we decided on skipping working on its integration this year?
- Is there actual coding work to do to achieve this?

So if you feel better to work on this by yourself, at least for CUPS and 
PAPPL, no problem, I can remove it.


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?

If it is simply an emulation of an IPP Printer (Printer Application) it 
would be hidden behind CUPS for applications and so no new backend is 
needed. CUPSD backend is sufficient.

If it is the sharing server of CUPS 3.x then the CUPS backend would also 
be the one to be used but we would need to add some extra functionality 
for extra control points, meaning that the project better gets titled: 
"Extend the CPDB CUPS backend for the sharing server of CUPS 3.x".

What is the situation, retitle the project or remove it?


These two looked rather viable for me:

PAPPL Scanning support
----------------------

PAPPL scanning support was already planned and worked on in GSoC 2022, 
but one of the two contributors has failed, and therefore we did not 
complete it. Therefore I have opened one project idea for its 
completion. There is even already a candidate investigating on what 
needs to get done.

What do you mean with

     but we are still a long ways away from having anything that can be
     merged and supported

Is too much missing for scanning so that one could complete it by the 
one project idea I have opened now? Would it need a complete 
re-architecturing of PAPPL? Would you prefer to do it by yourself from 
scratch, dropping all the GSoC contributions?

Should I better snap AirSANE to make scanner drivers snappable (but it 
will be confusing for users if an MF device has 2 daemons, one for 
printing and one for scanning)?


PAPPL presets
-------------

Is my idea in the feature request

https://github.com/michaelrsweet/pappl/issues/244

wrong? Or not implementable with current IPP? Or do you prefer to 
implement this by yourself.


So please tell me what should I remove or reformulate?

    Till

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

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 4201 bytes --]

Till,

> On Jan 16, 2023, at 3:06 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 16/01/2023 16:17, Michael Sweet wrote:
>> Till,
>> FWIW, some of the PAPPL project ideas aren't a good fit for GSoC, particularly the IPP Everywhere 2.0 stuff (still in flux, and something I am already working on) and presets.  The scan stuff is "nice to have" but we are still a long ways away from having anything that can be merged and supported.
> 
> OpenPrinting project ideas on
> 
> https://wiki.linuxfoundation.org/gsoc/google-summer-code-2023-openprinting-projects
> 
> Michael,
> 
> I was also in doubt about some ideas when I tried to create a description for them:
> 
> Update of OpenPrinting software to IPP Everywhere 2.0
> -----------------------------------------------------
> 
> - What are the exact differences between 1.1 and 2.0? Is it written somewhere to easily check?

The current draft of the 2.0 spec is at:

    https://www.pwg.org/ipp

The main changes are to make certain optional 1.1 things required in 2.0.  It will also depend on newer versions of several dependent specifications (PWG 5100.7 and 5100.13, in particular, have been updated since 1.1 and are in the final approval phase...)

> - Is 2.0 stable and complete enough for working towards it and is it also no subject of a quick replacement (by 2.1?)?

2.0 is marked as a prototype draft, which means it is ready for prototyping and is not expected to have significant technical changes.

WRT 2.1, we haven't even published 2.0 yet, but a 2.1 errata release MUST be backwards-compatible with 2.0 (conformance-wise) so I wouldn't worry about that.  Even 2.0 is just an incremental change from 1.1...

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

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

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

> These two looked rather viable for me:
> 
> PAPPL Scanning support
> ----------------------
> 
> PAPPL scanning support was already planned and worked on in GSoC 2022, but one of the two contributors has failed, and therefore we did not complete it. Therefore I have opened one project idea for its completion. There is even already a candidate investigating on what needs to get done.
> 
> What do you mean with
> 
>    but we are still a long ways away from having anything that can be
>    merged and supported

I mean that the current work has laid the foundation but we haven't actually implemented everything needed to handle IPP and/or eSCL requests, route them through the scanner driver, get the scan data from the scanner, and feed it back to the client.

> ...
> Should I better snap AirSANE to make scanner drivers snappable (but it will be confusing for users if an MF device has 2 daemons, one for printing and one for scanning)?

Honestly that is the simplest way since ALL of the scanners we planned on supporting via PAPPL printer applications are already supported by SANE.

> PAPPL presets
> -------------
> 
> Is my idea in the feature request
> 
> https://github.com/michaelrsweet/pappl/issues/244
> 
> wrong? Or not implementable with current IPP? Or do you prefer to implement this by yourself.

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.

________________________
Michael Sweet


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Till Kamppeter]

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.

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

>> What do you mean with
>>
>>     but we are still a long ways away from having anything that can be
>>     merged and supported
> 
> I mean that the current work has laid the foundation but we haven't actually implemented everything needed to handle IPP and/or eSCL requests, route them through the scanner driver, get the scan data from the scanner, and feed it back to the client.
>

This is the intention of the project idea which I have opened. The 
contributor should code exactly that. The eSCL parser is already there.

>> ...
>> Should I better snap AirSANE to make scanner drivers snappable (but it will be confusing for users if an MF device has 2 daemons, one for printing and one for scanning)?
> 
> Honestly that is the simplest way since ALL of the scanners we planned on supporting via PAPPL printer applications are already supported by SANE.
>

One must note that it is retro-fit only, no way to create a native 
Scanner Application with it, and as I said, on multi-function devices 
one has two completely different daemons. It could be a stop-gap if the 
current PAPPL scanning project fails.

I also need to see whether this is still actively maintained.

>> PAPPL presets
>> -------------
>
[...]

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

Talking about Gutenprint was only an example, but Gutenprint is 
naturally very extreme and here one should go beyond my initial idea 
creating a specialized UI in the web interface.

    Till

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

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

Till,

> On Jan 16, 2023, at 6:06 PM, Till Kamppeter <till.kamppeter@gmail.com> 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


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Till Kamppeter]

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

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

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 5659 bytes --]

Till,

On Jan 17, 2023, at 5:49 PM, Till Kamppeter <till.kamppeter@gmail.com> 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


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]