Differences

This shows you the differences between two versions of the page.

--- gsoc:google-summer-code-2023-openprinting-projects [2023/01/16 01:23]
till
+++ gsoc:google-summer-code-2023-openprinting-projects [2023/01/19 14:44] (current)
till [Scanning support in PAPPL]
@@ Line 25: / Line 25: @@
 ====Printer Drivers get Printer Applications====
+**OR%%  %%The New Architecture** ([[https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning|What it is]], [[https://www.youtube.com/watch?v=P22DOu_ahBo|Video]])
 [[https://github.com/OpenPrinting/cups/|CUPS]], printing environment used by Linux and most other non-Windows operating systems, supports the different printer models with the help of printer drivers, consisting of PPD (PostScript Printer Description) files to describe the printer's capabilities, filters to convert the incoming print jobs into the printer's native language, and sometimes also backends, to support non-standard communication protocols between the computer and the printer hardware.
@@ Line 65: / Line 67: @@
 So we are going to replace SANE in the role of an interface between scanning user applications and scanner drivers by the sandboxing-ready eSCL. SANE will continue to exist, but to provide the legacy scanner drivers enclosed in a Scanner Application.
-Work on extending the Printer Application framework [[https://github.com/michaelrsweet/pappl/|PAPPL]] has already been [[https://github.com/Bhavna2020/GSoC-2021|started in GSoC 2021]] and [[https://gist.github.com/Rishabh-792/b1a2960b7e0e3d2bd3a5f4db3d260fc0|continued in GSoC2022]].
+Work on extending the Printer Application framework [[https://github.com/michaelrsweet/pappl/|PAPPL]] has already been [[https://github.com/Bhavna2020/GSoC-2021|started in GSoC 2021]] and [[https://gist.github.com/Rishabh-792/b1a2960b7e0e3d2bd3a5f4db3d260fc0|continued in GSoC 2022]].
 ====What we are currently doing at OpenPrinting====
@@ Line 97: / Line 99: @@
 ======Project Ideas======
-=====Adding support for the new functionality/attributes of IPP Everywhere 2.x to PAPPL, libcupsfilters, Common Print Dialog Backends (CPDB), ...=====
+=====Adding support for the new functionality/attributes of IPP Everywhere 2.x to libcupsfilters and the Common Print Dialog Backends (CPDB)=====
- contributor full-size (350 hours).
+-2 contributors full-size (350 hours).
 Driverless IPP printing is implemented with four, very similar standards, IPP Everywhere, AirPrint, Mopria, and Wi-Fi Direct Print. Most [[https://openprinting.github.io/printers/|printers]] qualify to be driverless as the support [[https://support.apple.com/en-us/HT201311|Apple's Airprint]], the standard which got widely used first, to allow printing from iPhones and other iOS devices, but IPP Everywhere from the Printer Working Group is the first free and open standard.
@@ Line 107: / Line 109: @@
 The software provided on OpenPrinting is all based on IPP Everywhere 1.x and to make use of printer features covered by the new version of the standard it needs to get updated.
-The contributor's task is to compare the old and the new specifications and to update everything to conform with [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve20-20221107.pdf|IPP Everywhere 2.0]].
+The contributor's task is to add the new features according to the new specifications and to update everything to conform with [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve20-20221107.pdf|IPP Everywhere 2.0]], [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20221027.pdf|IPP Driver Replacement Extensions v2.0]], and [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobext21-20221212.pdf|IPP Job Extensions v2.1]]. Especially the libcupsfilters and CPDB must "understand" the new attributes and choices, libcupsfilters needs to implement the new attribute's functionality, and CPDB to carry through the new attributes to the print dialogs.
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Ira McDonald (blueroofmusic at gmail dot com), TBD
@@ Line 140: / Line 142: @@
 For the CPDB integration we do not need UI design work.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), GNOME/GTK developers, Qt developers, TBD
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Firefox/Thunderbird/Mozilla developers, Chrome developers, LibreOffice developers, TBD
 Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
 Code License: MIT, GPL-2+ and LGPL-2+
-=====CPDB backend for IPP infrastructure/cloud printers=====
-contributor full-size (350 hours).
@@ Line 159: / Line 154: @@
 contributor full-size (350 hours).
-In the Google Summer of Code 2021, Bhavna Kosta has started the work on [[https://github.com/Bhavna2020/GSoC-2021|Scanning support in PAPPL]] so that [[https://github.com/michaelrsweet/pappl/|PAPPL]] not only can be used for creating Printer Applications (emulation of a driverless IPP printer) but also for creating Scanner Applications (emulation of a driverless IPP/eSCL scanner), or even an emulation of a driverless IPP multi-function device.
+In the Google Summer of Code 2021, Bhavna Kosta has started the work on [[https://github.com/Bhavna2020/GSoC-2021|Scanning support in PAPPL]] (Talk on OpenPrinting micro-conference 2021: [[https://linuxplumbersconf.org/event/11/contributions/1029/attachments/785/1474/Scanning%20in%20PAPPL.pdf|Slides]], [[https://youtu.be/5KogjLb1Hb4?t=15600|Video]]) so that [[https://github.com/michaelrsweet/pappl/|PAPPL]] not only can be used for creating Printer Applications (emulation of a driverless IPP printer) but also for creating Scanner Applications (emulation of a driverless eSCL scanner), or even an emulation of a driverless IPP multi-function device.
 She has created the [[https://github.com/michaelrsweet/pappl/tree/scanning|needed data structures and API functions]] needed to extend PAPPL for supporting scanners.
@@ Line 186: / Line 181: @@
 contributor full-size (350 hours).
+[[https://openprinting.github.io/achievements/#cups-browsed|cups-browsed]] is a helper daemon for CUPS to automatically set up network printers. In the beginning it was to overcome that when CUPS from 1.6.x on used DNS-SD instead of its own browsing/broadcasting, it did not auto-setup client queues any more.
+With the time it got lots of more functionality: Legacy CUPS browsing/broadcasting for interoperability with CUPS 1.5.x and older (often in long-term support enterprise distros), clustering, manually and automatically, also for clusters of printers of completely different types, user has one "universal" print queue and by their option settings job goes to the correct printer. Also filtering lists of many printers is supported, and everything can be configured/fine-tuned by the user or admin.
+With CUPS already having its temporary queue functionality for network printers without need of explicit manual setup, and the Common Print Dialog Backends getting into the print dialogs and talking to CUPS with modern interfaces, we do not need automatic queue creation for network printers any more, but the other functionality of cups-browsed is still very useful.
+So we do not want to discontinue cups-browsed, but take it into the New Architecture of printing, giving it the appropriate modern interface. Currently cups-browsed discovers printers via DNS-SD, and then creates (or not creates) local print queues pointing to them according to the rules in its configuration file. But currently it creates classic CUPS queues, with PPD files generated according to the printer's IPP attributes. What we need is make it working with CUPS 3.x, which drops PPD files and classic printer drivers.
+For this we want tom turn it into a Printer Application, the new printer driver format, emulating a driverless IPP printer. This way CUPS can access the printers created by cups-browsed and create temporary queues for them on-demand. Internally we define with configuration file what these queues should do: Clusters, retro-fit to old CUPS, ...
+The contributor's task is to implement this transition, using PAPPL for all standard elements of a Printer Application, like daemon, IPP parser, web admin interface, ... They will make cups-browsed create a queue in the Printer Application if appropriate destination printers get discovered, and remove it when these printers disappear (turned off, user leaves network, ...). CUPS will simply pick up on the emulated IPP printers then. And there will be a web interface to be created, for the configuration of the clusters, filter rules, .... one does not need to edit cups-browsed.conf manually any more.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Deepak Patankar (patankardeepak04 at gmail dot com), TBD
+Desired knowledge: %%C%%, CUPS
+Code License: Apache 2.0
@@ Line 194: / Line 204: @@
 contributor full-size (350 hours).
-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 Gutenprint, 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.
+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. On an extra web interface page you can create and edit any number of named presets.
@@ Line 206: / Line 216: @@
 This page contains a field for the preset's name at the top, being empty if you are creating a new preset. You enter the desired name, only with a valid name you can save your preset.
-Under that you see the same options as on the "Printing Defaults" page, both the IPP standard attributes and the vendor options, but in the choices for each option is an extra one "Do not set" to not include this setting in the template. This is chosen by default in a newly created template. The rest of the choices are the ones which there are also under "Printing Defaults" but with the choice which is the current default under "Printing Defaults" having " (current default)" added, to ease the orientation for the user. To define the template, the user chooses the settings for the desired attributes/options and leaves the attributes/options they do not to include in the template on "Do not set". If the user edits the name of the template, it gets renamed. Then the user clicks on "Save" to save the template. This brings them back to the list view, with the new template in the list.
+Under that you see the same options as on the "Printing Defaults" page, both the IPP standard attributes and the vendor options, but in the choices for each option is an extra one "Do not set" to not include this setting in the preset. This is chosen by default in a newly created preset. The rest of the choices are the ones which there are also under "Printing Defaults" but with the choice which is the current default under "Printing Defaults" having " (current default)" added, to ease the orientation for the user. To define the preset, the user chooses the settings for the desired attributes/options and leaves the attributes/options they do not to include in the template on "Do not set". If the user edits the name of the preset, it gets renamed. Then the user clicks on "Save" to save the preset. This brings them back to the list view, with the new preset in the list.
-The user can for example create a "photo" template choosing photo paper, 4x6 size, and high print quality, or a "draft" template choosing recycled paper and draft print quality. With Gutenprint they could fine-tune a lot of knobs for each paper type, photo style, ... and quickly get back to all their preferred settings by choosing the right template.
+The user can for example create a "photo" preset choosing photo paper, 4x6 size, and high print quality, or a "draft" preset choosing recycled paper and draft print quality. With Gutenprint they could fine-tune a lot of knobs for each paper type, photo style, ... and quickly get back to all their preferred settings by choosing the right template.
-There should be some standard IPP attribute for such templates (is it "job-presets"? Please correct me.) to be selected by the client and the Printer Application should enumerate all the user defined presets with their names in the response to a get-printer-attributes IPP request ("job-presets-supported=None,Preset1,Preset2,..."?). None should be always there to not select any of the presets.
+The user-defined presets are made available to the client (print dialog, or better CUPS backend of the Common Print Dialog Backends, CPDB) by the "job-presets-supported" entry in the answer to the "get-printer-attributes" IPP request and so we get an option to select a preset in the print dialogs and the client (print dialog, CPDB backend) adds the settings described in the preset to the job.
 This, I think, is the best way to cope with printer drivers which have extended settings not mappable to standard IPP attributes, especially for complex drivers like Gutenprint, but also for the retro-fitting Printer Applications as the PPD files (treated by pappl-retrofit) always have non-standard options which end up as vendor options in a PAPPL-based Printer Application, not mapped to standard IPP options.
@@ Line 220: / Line 230: @@
 For the user experience with Gutenprint this preset feature would be even more important than the switchover to a native Printer Application.
-[[https://ftp.pwg.org/pub/pwg/ipp/registrations/reg-ipppreset-20171214.odt|Description of "job-presets" attribute]]
+  * [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20221027.pdf|IPP Driver Replacement Extensions v2.0]]
+  * [[https://ftp.pwg.org/pub/pwg/ipp/registrations/reg-ipppreset-20171214.odt|Description of "job-presets" attribute]]
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD
@@ Line 262: / Line 273: @@
 contributor full-size (350 hours).
+To protect a free software project worked on by several contributors against regressions caused by a committed change, one needs frequent, automated testing of the code, base, ideally triggered by every commit into the repository. This is called Continuous Integration (CI).
+What is triggered on each commit is usually some static analysis of the code using common, specialized tools and also build and execution tests, usually doing `./configure; make; make test` on different system platforms.
+This naturally requires test scripts/programs which are compiled and run by the `make test` step. For CUPS for example the daemon is started (on an unprivileged port so that it does not need root), queues created and listed, jobs sent, the logs checked whether everything went OK, ... For Ghostscript a large collection of input files (gathered from bug reports) is processed and converted into raster formats.
+The contributor's task here is to write test programs for the different OpenPrinting projects so that `make test` does something useful, being efficient to catch regressions. They should exercise important functionality of the software with different parameters and analyse logs and output files to check whether the program did the expected work.
+Test programs are also needed for the so-called 'autopkgtest' tests which are added to Debian packages and executed whenever the package is uploaded to Debian or Ubuntu.
+In addition, instruction files and shell scripts are needed to build the software on different platforms/environments, run tests, create GitHub Actions (for the automatic triggering on each commit ...).
+This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: ([[https://openprinting.github.io/OpenPrinting-News-September-2022/#openprinting-micro-conference-on-the-linux-plumbers-2022|Summary]], [[https://lpc.events/event/16/contributions/1161/attachments/942/1851/lpc-printing-ci-2022.pdf|Slides]], [[https://www.youtube.com/watch?v=c--Uki7cvGE|Video]])
+Here you can see what we already have in terms of CI, and what is missing ...
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD
+Desired knowledge: C, Shell, PAPPL, CUPS, CI
+Code License: Apache 2.0, MIT
 =====GNOME Control Center: List and handle IPP print services for the New Architecture=====

Wiki

User Tools

Site Tools

Differences

Page Tools