Differences

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

--- gsoc:google-summer-code-2024-openprinting-projects [2024/01/20 22:12]
till
+++ gsoc:google-summer-code-2024-openprinting-projects [2024/04/01 09:28] (current)
till
@@ Line 8: / Line 8: @@
 Mailing list: [[https://lore.kernel.org/printing-architecture/|printing-architecture at lists dot linux dot dev]] ([[https://subspace.kernel.org/lists.linux.dev.html|Instructions]])
-IRC: #openprinting on [[https://libera.chat/|Libera.Chat]]
+Telegram: [[https://t.me/+RizBbjXz4uU2ZWM1|OpenPrinting Channel]]
+Mastodon/Fediverse: [[https://ubuntu.social/tags/OpenPrinting|#OpenPrinting]]
 Our code repositories: [[https://github.com/OpenPrinting|OpenPrinting GitHub]]
@@ Line 32: / Line 34: @@
   * [[https://podcast.asknoahshow.com/368?t=2837|Ask Noah: Till Kamppeter on how OpenPrinting improved printing with Linux/Unix]]
   * [[https://www.youtube.com/watch?v=m5QKJH9tDjQ|Linux Saloon: Till Kamppeter about how he got Snap enthusiast]]
+====Talk about OpenPrinting====
+  * [[https://fosdem.org/2024/schedule/event/fosdem-2024-1930-openprinting-we-make-printing-just-work-/|OpenPrinting - We make printing just work! Till Kamppeter, FOSDEM 2024, Brussels, Belgium]]
 ====Printer Drivers get Printer Applications====
@@ Line 134: / Line 140: @@
 =====Desktop integration: CPDB support for the print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice=====
--2 contributors full-size (350 hours).
+-2 contributors full-size (350 hours), Level of difficulty: Hard
 Most print jobs are sent via the print dialog of a desktop application, like evince, Chrome, LibreOffice, DarkTable, … Print dialogs are usually, like “Open …” or “Save as …” dialogs, provided by the GUI toolkits, in most cases GTK or Qt, sometimes applications come also with their own creations, like LibreOffice or Firefox.
@@ Line 153: / Line 159: @@
 The contributor's task is to get CPDB into the print dialogs upstream, the UI of them does not need to be changed. Dialogs to be treated are Mozilla for Firefox and Thunderbird, and also LibreOffice, and any other application-specific dialog if we have missed it by now. For LibreOffice there was already worked on CPDB support back in 2017, but in the meantime things have changed and the dialog needs to get updated, especially for the new features of CPDB 2.x (human-readable strings/translations, option groups, ...).
+CPDB support for the print dialog of the Chromium Browser is already done by Kushagra Sharma in GSoC [[https://github.com/kushagra20251/GSoC/|2023]].
 For the CPDB integration we do not need UI design work.
@@ Line 164: / Line 172: @@
 =====Desktop Integration: Update system-config-printer for the New Architecture of printing=====
-=====Desktop Integration: User interfaces for using OAuth2 with printers and scanners=====
+contributor full-size (350 hours), Level of difficulty: Intermediate
-=====Replace QPDF by PDFio as PDF manipulation library in libcupsfilters (cfFilterPDFToPDF() filter function and others)=====
+Originally, we already had discontinued the development of system-config-printer and put it into maintenance mode, only fixing bugs and collecting UI translations.
-contributor full-size (350 hours).
+But system-config-printer s still used a lot. There are practically only 3 printer setup tools around: The "Printers" module of GNOME Control Center, the printer manager of KDE Settings, and system-config-printer. There are many more desktop environments than just GNOME and KDE, and distributions using many of those use system-config-printer as their printer setup tool.
-Like [[https://openprinting.github.io/cups/|CUPS]], [[https://github.com/OpenPrinting/libcupsfilters|libcupsfilters]] is principally written in regular C and not in %%C++%%. We want to avoid %%C++%% as it has often problems with binary compatibility and the mechanism with which the Debian/Ubuntu build services auto-detect dependencies between Debian packages get very awkward with %%C++%%.
+For switching distributions into the New Architecture, meaning from CUPS 2.x to CUPS 3.x, the printer setup tool needs to get appropriately adapted, to list IPP print destinations with appropriate configuration options, especially access to their web admin interfaces, and assign Printer Applications to non-driverless printers.
-But libcupsfilters still depends on one library which is written in %%C++%%, [[https://github.com/qpdf/qpdf/|QPDF]], a library for manipulating PDF files: Scaling up and down, moving around on the page, rotating, combining several source pages on one destination page, turning filled PDF forms into straight PDF, ... QPDF is used by the filter functions cfFilterPDFToPDF(), cfFilterBannerToPDF(), cfFilterGSToRaster(), and cfFilterRasterToPDF().
+One could also think about dropping the concept of printer setup tools altogether as modern, driverless printers are simply there, but it is not very intuitive for a user to have to find a Printer Application and install it to make a non-driverless printer working and that for driverless printers and Printer Applications there are web admin interfaces and how to access them.
-Michael Sweet, author of CUPS, has some years ago started the [[https://www.msweet.org/pdfio/|PDFio]] project. This is a PDF handling and manipulation library, as QPDF is, but it is fully written in standard, regular C, not in %%C++%%.
+So to assure continued coverage of all desktops we need to revive development of system-config-printer and make it supporting the New Architecture, but as with GNOME Control Center and KDE Settings we also need to keep the old functionality, to allow a switchover to the new CUPS at any time and already while still using CUPS 2.x, have a better support for driverless printers.
-Therefore we want to replace the use of QPDF by PDFio and this is what this GSoC project is about.
+And this is the contributor's task in this project.
-But for such a switchover we must take into account that QPDF is a complex and sophisticated project with a lot of features (it got even new features by two GSoC projects of OpenPrinting) while PDFio is a young project run as one of the many small projects by Michael Sweet and we must be very careful to see whether it does not miss any important feature. Especially we must look after correct printing of filled-in PDF forms and PDF annotations.
+Note that system-config-printer is written in Python.
-So part of the project will be investigation of suitability and perhaps also work with Mike to get needed features added. And after the switchover thorough testing is needed to avoid any regressions after this impactful change.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
-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
+Desired knowledge: Python, C, CUPS
-Desired knowledge: %%C/C++%%, CUPS
+Code License: GPL-2+ (GPL 2 or any later version)
-Code License: Apache 2.0
+=====Desktop Integration: User interfaces for using OAuth2 with printers and scanners=====
+contributor full-size (350 hours), Level of difficulty: Hard
-=====CPDB backend for IPP infrastructure/cloud printers=====
+From version 2.5.x on CUPS uses OAuth2 ([[https://en.wikipedia.org/wiki/OAuth|Open Authorization]]) for authorization purposes and drops the formerly used Kerberos with the CUPS 3.x generation. See latest state-of-the-art presentation from Michael Sweet: [[https://events.canonical.com/event/35/contributions/285/attachments/66/111/oos-cups-september-2023.pdf|slides]], [[https://www.youtube.com/watch?v=vzu0FIyDfOo|video]], slide 11).
-=====Turn cups-browsed into a Printer Application=====
+Authorization in printing is needed to once protect the data of confidential jobs, and second, to protect printer resources, like toner or paper.
-=====Printer Application for Braille embossers=====
+OAuth2, standard for authorization for internet services ("Log in with Google") is also used as authorization standard for IPP (Internet Printing Protocol) printing.
+As described in a talk on the OpenPrinting microconference on Linux Plumbers 2022 ([[https://lpc.events/event/16/contributions/1165/attachments/1093/2097/LPC2022_OAuth2_for_IPP.pdf|slides]], [[https://www.youtube.com/watch?v=8UjrKos6LuY|video]]) when accessing an IPP printer requiring authorization, it returns the URL to request the authorization from the authorization server in the response to the get-printer-attributes IPP request. Now the print client (print dialog, printer setup tool) has to open the URL in a browser so that the user can log in, create an account, or whatever the authorization server needs to identify the user. On success the server returns a URL with authorization code with which the client can get the access code to the printer.
-=====Adding support for the new functionality/attributes of IPP Everywhere 2.x to libcupsfilters and the Common Print Dialog Backends (CPDB)=====
+This works for all kinds of IPP print destinations which require authorization, not only physical network printers but also print servers and IPP-based cloud printing services.
--2 contributors full-size (350 hours).
+The contributor's task is to add the functionality to open the authorization server URLs and to supply the access code to the printer to the desktop printing workflow. This can be implemented in print dialogs or perhaps even made independent of concrete print dialogs by the [[https://github.com/OpenPrinting/cpdb-backend-cups|CPDB backend for CUPS]] triggering a D-Bus service for opening the URL (perhaps desktops always have such a thing?). Investigating what the best solution is for this task is part of the project.
-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.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), TBD
-IPP Everywhere is under continuous development. The current version printers are certified on is 1.1, but 2.0 is close to its release. It adds new attributes to cover the most recent printers.
+Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
-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.
+Code License: Apache 2.0, MIT, GPL-2+ and LGPL-2+
-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.
+=====Integrating C-based OpenPrinting projects in OSS-Fuzz testing=====
-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
+contributor full-size (350 hours), Level of difficulty: Intermediate
-Desired knowledge: %%C/C++%%, CUPS
+[[https://google.github.io/oss-fuzz|OSS-Fuzz]] is a project aimed at finding vulnerabilities in open-source projects that are critical to the Internet infrastructure. It is powered by Google and was initiated in response to [[https://heartbleed.com|Heartbleed]], an OpenSSL vulnerability that could have been discovered with classic vulnerability discovery techniques. The codebases integrated into OSS-Fuzz are run multiple times with randomly crafted inputs in an approach called fuzzing.
-Code License: Apache 2.0
+Most of OpenPrinting's code is written in C, which is susceptible to memory corruption bugs. OpenPrinting's projects do not use fuzzing, with a single exception: CUPS has a [[https://github.com/OpenPrinting/cups/blob/master/cups/fuzzipp.c|custom fuzzer]] run when testing the build, for a fixed number of iterations.
+Due to the compatibility of C projects with OSS-Fuzz, we would like to abandon the existing fuzzer and integrate the following C-based OpenPrinting projects into OSS-Fuzz (projects in priority order):
-=====CPDB support for application's print dialogs: Firefox, Chromium, LibreOffice, ...=====
+  * CUPS
+  * libcups
+  * cups-local
+  * cups-sharing
+  * libcupsfilters
+  * cups-filters
+  * cups-browsed
+  * PAPPL
+  * cpdb-libs
+  * cpdb-backend-cups
+  * libppd
+  * pappl-retrofit
-contributor full-size (350 hours).
+The purpose is to use the Google Summer of Code timeframe to create a mature OSS-Fuzz integration that maximises the number of fuzzed projects and fuzzing efficiency, as measured by coverage and execution speed.
-Most print jobs are sent via the print dialog of a desktop application, like evince, Chrome, LibreOffice, DarkTable, … Print dialogs are usually, like “Open …” or “Save as …” dialogs, provided by the GUI toolkits, in most cases GTK or Qt, sometimes applications come also with their own creations, like LibreOffice or Chromium.
+The contributor should work on:
-Problem here is usually not the design of the dialog itself, most are actually easy to use, but the way how they connect to CUPS (and also to other print technologies) and how well this connection code is maintained and kept up-to-date.
+  * Coordinating with OpenPrinting which projects have highest priority and also which functionality of them, to get the best from the limited GSoC time
+  * Creating Docker-based build environments
+  * Writing libFuzzer fuzz targets
+  * Creating a corpus of data
+  * Understanding and implementing the [[https://google.github.io/oss-fuzz/advanced-topics/ideal-integration/|OSS-Fuzz best practices]]
+  * Coordinating with the OpenPrinting developers to patch the vulnerabilities found by OSS-Fuzz
+  * Analysing the found vulnerabilities and interpreting their details to deduce vulnerability classes that can be mitigated in bulk.
-GUI toolkit projects are large projects, often with long release cycles and all with a certain inertia, and there are things which many people are eager to work on, and others, like print dialogs, which have to be there but no one is really motivated to push their development forward and do the needed maintenance work.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
-An important part of the maintenance of a GUI toolkit is that it interfaces well and correctly with the underlying operating system, graphics, sound, storage, …, and printing! The OS is under continuous development, things are changing all the time, components get replaced by others, printing is CUPS for 23 years, but within CUPS we have also changes, and they need to be taken care of in the print dialogs.
+Desired knowledge: C, fuzzing
-Several years back, CUPS started to create temporary queues for driverless IPP network printers (or remote CUPS printers, which are emulations of IPP printers), which are only physically available when they are accessed (capabilities are polled or job printed). Print dialogs used an old API which did not support this, the temporary queues did not appear in the dialog, a helper daemon, cups-browsed had to convert the temporary queues into physical queues as a workaround. The correct solution had been to change the print dialogs to a newer CUPS API which supports these queues, but no one at the GUI toolkit projects has felt responsible and taken the time for this update for many years. Only recently this got fixed.
+Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
-This made me introducing the Common Print Dialog Backends (CPDB) back in 2017, a de-coupling of the print technology (CUPS, print-to-file, that time also Google Cloud Print) from the GUI. The GUI projects have to adopt the CPDB support only once and then OpenPrinting (or any upcoming cloud printing projects) takes care of the CPDB backend for the print technologies to be up-to-date with any changes. This way print technology projects can react quickly and are not dependent any more on the GUI toolkit’s inertia.
+=====Official OCI containers (Docker, ROCKs, podman, ...) of CUPS and Printer Applications=====
-The print dialogs of the major GUI toolkits, GTK, Qt, got CPDB support added in GSoC 2022, but several applications come with their own creation of a print dialog. AFAIK these are Firefox/Thunderbird (Mozilla), Chromium/Chrome (Google), and LibreOffice. Also these dialogs need to get CPDB support to make CPDB universal.
+contributor full-size (350 hours), Level of difficulty: Intermediate
-Then we are especially prepared for the switch to CUPS 3.x which does not support PPD files any more, as the CUPS backend of CPDB is already using only CUPS APIs not handling PPD files. And we are also prepared for IPP infrastructure/cloud printing for which we also want to create a CPDB backend (see below).
+[[https://ubuntu.com/blog/ubuntu-core-an-immutable-linux-desktop|Immutable desktop operating system distributions]] are currently one of the most talked about subjects in free software. There is barely passing a week where one does not hear about any new distribution of this kind.
-The contributor's task is to get CPDB into the print dialogs upstream, the UI of them does not need to be changed. Dialogs to be treated are Mozilla for Firefox and Thunderbird, Chromium/Chrome, LibreOffice, and any other application-specific dialog. For LibreOffice there was already worked on CPDB support back in 2017, but in the meantime things have changed and the dialog needs to get updated, especially for the new features of CPDB 2.x (human-readable strings/translations, option groups, ...).
+Immutable distributions are made up of a read-only (immutable) core file system and applications are installed also as immutable container images. This gives more ease of use, reliability, and security, as the file systems cannot be modified and messed up, but instead, only replaced and updated as a whole, and also each application is in its own security capsule not being able to access any of the other applications or the system. This practice is commonplace on smartphones and got overtaken to PCs.
-For the CPDB integration we do not need UI design work.
+On most immutable distributions, one installs desktop applications in the [[https://flatpak.org/|Flatpak]] format. This gives a huge choice of apps, but Flatpak cannot be used for GUI-less system applications and daemons. The solution for adding this type of software is the use of an alternative container format. And here [[https://opencontainers.org/|OCI containers]] are the solution. The container images can be downloaded from app-store-alike services like the [[https://hub.docker.com/|Docker Hub]] and be installed an run via [[https://www.docker.com/|Docker]], [[https://podman.io/|podman]] or similar.
-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
+If you have a look at the Docker Hub you will find several container images for CUPS, but none of them is the official one, none of them comes from OpenPrinting. This makes the choice difficult, to find the most suitable one and also not get hit by a malicious one. So an official OCI container of CUPS is the first thing we need, to be able to have always the latest release of CUPS, directly from its developers.
-Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
+Another point is how to add printer and scanner drivers to immutable distributions. For this we also need containers of Printer and Scanner Applications.
-Code License: MIT, GPL-2+ and LGPL-2+
+The contributor's task is to create these containers and infrastructure and scripting to ease their maintenance, like for example update automation when for one or another of their components a new upstream version is released, or for automated test building and testing.
+There are tools for creating such images, for example [[https://discourse.ubuntu.com/c/rocks/|rockcraft]] which uses build instruction files similar to Snap (see this [[https://events.canonical.com/event/31/contributions/228/|workshop]]: [[https://events.canonical.com/event/31/contributions/228/attachments/132/209/%5Bslidedeck%5D%20Container%20craftsmanship_%20from%20a%20Pebble%20to%20a%20ROCK.pdf|slides]], [[https://www.youtube.com/watch?v=BDXZxp3aFBY|video]]) and so we can use our [[https://github.com/OpenPrinting/cups-snap/|CUPS Snap]] as base, but we will not require the contributor to use a special, given tool.
+Desired knowledge: Shell, Python, packaging, immutable OS distributions, GIT
-=====Scanning support in PAPPL=====
+Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
-contributor full-size (350 hours).
+=====Replace QPDF by PDFio as PDF manipulation library in libcupsfilters (cfFilterPDFToPDF() filter function and others)=====
-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.
+contributor full-size (350 hours), Level of difficulty: Hard
-She has created the [[https://github.com/michaelrsweet/pappl/tree/scanning|needed data structures and API functions]] needed to extend PAPPL for supporting scanners.
+Like [[https://openprinting.github.io/cups/|CUPS]], [[https://github.com/OpenPrinting/libcupsfilters|libcupsfilters]] is principally written in regular C and not in %%C++%%. We want to avoid %%C++%% as it has often problems with binary compatibility and the mechanism with which the Debian/Ubuntu build services auto-detect dependencies between Debian packages get very awkward with %%C++%%.
-After that, in the Google Summer of Code 2022, Rishabh Maheshwari has then [[https://gist.github.com/Rishabh-792/b1a2960b7e0e3d2bd3a5f4db3d260fc0|implemented an eSCL parser]] so that Scanner Applications emulate eSCL scanners, the standard protocol which the hardware industry uses for driverless scanning.
+But libcupsfilters still depends on one library which is written in %%C++%%, [[https://github.com/qpdf/qpdf/|QPDF]], a library for manipulating PDF files: Scaling up and down, moving around on the page, rotating, combining several source pages on one destination page, turning filled PDF forms into straight PDF, ... QPDF is used by the filter functions cfFilterPDFToPDF(), cfFilterBannerToPDF(), cfFilterGSToRaster(), and cfFilterRasterToPDF().
-Next steps to complete the support are the following:
+Michael Sweet, author of CUPS, has some years ago started the [[https://www.msweet.org/pdfio/|PDFio]] project. This is a PDF handling and manipulation library, as QPDF is, but it is fully written in standard, regular C, not in %%C++%%.
-  * Implementation of the PAPPL internal functionality, integration of the eSCL interpreter code, response to the eSCL inquires, interface for callback functions with the actual scanner driver code, ...
+Therefore we want to replace the use of QPDF by PDFio and this is what this GSoC project is about.
-  * Create a test scanner driver emulating a scanner without needing actual scanner hardware, for example serving out static images from a directory.
-  * A retro-fit SANE interface to be added to the [[https://github.com/OpenPrinting/pappl-retrofit/|pappl-retrofit]] project (similar to [[https://github.com/SimulPiscator/AirSane|AirSANE]]), so that all already existing scanner drivers could be converted to Scanner Applications and this way scanning for clients distributed in sandboxed packages (like Snap) or on all-Snap OS distributions is assured.
-  * Unit tests
-  * Documentation
-The contributor's task to implement the above-mentioned components to complete the framework needed by all Scanner Applications. With this done, only code for the particular group of scanners to support (scanner driver) needs to be added to PAPPL.
+But for such a switchover we must take into account that QPDF is a complex and sophisticated project with a lot of features (it got even new features by two GSoC projects of OpenPrinting) while PDFio is a young project run as one of the many small projects by Michael Sweet and we must be very careful to see whether it does not miss any important feature. Especially we must look after correct printing of filled-in PDF forms and PDF annotations.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Rishabh Maheshwari (rishphalod7 at gmail dot com), Deepak Patankar (patankardeepak04 at gmail dot com)
+So part of the project will be investigation of suitability and perhaps also work with Mike to get needed features added. And after the switchover thorough testing is needed to avoid any regressions after this impactful change.
+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
 Desired knowledge: %%C/C++%%, CUPS
 Code License: Apache 2.0
 =====Turn cups-browsed into a Printer Application=====
-contributor full-size (350 hours).
+contributor full-size (350 hours), Level of difficulty: Intermediate
 [[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.
@@ Line 296: / Line 323: @@
 Code License: Apache 2.0
+=====Converting Braille embosser support into a Printer Application=====
-=====PAPPL-based Printer Applications: Option setting presets via web interface=====
+contributor full-size (350 hours), Level of difficulty: Hard
-contributor full-size (350 hours).
+cups-filters currently supports Braille embossers through a series of PPD files and shell scripts that convert documents into a textual layout, convert the text into Braille dots, and convert the Braille dots to braille embosser-specific formats.
-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.
+For long-term support and wide availability, this needs to be converted to the newer CUPS infrastructure, Printer Applications.
-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.
+The contributor's task is thus:
-On this page you can create, copy, edit, and delete presets.
+  * Converting these shell scripts into filter functions in libcupsfilters
+  * Creating a Printer Application that exposes Braille embossers configuration to users
-You see a list of the existing presets, each with buttons for copy, edit, and delete. At the top you see the create button.
+The contributor does not need to own any specific hardware, a comparison can be made between the output of the existing shell-script-based implementation and the output of the converted implementation.
-If you click on the create button, you will get on the page for editing a preset.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Samuel Thibault, Braille expert (samuel dot thibault at ens-lyon dot org)
-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.
+Desired knowledge: %%C/C++%%, Shell, CUPS
-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" 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.
-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.
-This project should be implemented in [[https://github.com/michaelrsweet/pappl/|PAPPL]] and not in [[https://github.com/OpenPrinting/pappl-retrofit/|pappl-retrofit]], as the problem occurs for both native (developed from scratch) and retro-fitting Printer Applications (retro-fitting a classic CUPS driver with PPD files into a Printer Application). One can easily see it when one takes the (retro-fitting) [[https://github.com/OpenPrinting/gutenprint-printer-app|Gutenprint Printer Application]]. See also the screenshot of the "Printing Defaults" page in the [[https://snapcraft.io/gutenprint-printer-app|Snap Store listing]]. And this will not change when we turn Gutenprint into a native Printer Application (see below).
-This was already considered in the discussion during earlier work on the Gutenprint Printer Application.
-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/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
-Desired knowledge: %%C%%, PAPPL, CUPS
 Code License: Apache 2.0
 =====Make a native Printer Application from Gutenprint=====
-contributor full-size (350 hours).
+contributor full-size (350 hours), Level of difficulty: Hard
 [[http://gimp-print.sourceforge.net/|Gutenprint]] is a high-quality printer driver for a wide range of inkjets, especially Epson and Canon, dye-sublimation printers and even monochrome PCL laser printers. It does not only cover many printers to give them support under Linux and free software operating systems at all, but also is optimized for highest possible print quality, so that at least on some printers and with the right settings you can even get better print quality than with the original (Windows/Mac) drivers.
@@ Line 365: / Line 372: @@
 Code License: Apache 2.0
+=====CI Testing programs for libpappl-retrofit and libppd=====
-=====CI Testing programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, ...=====
+contributor full-size (350 hours), Level of difficulty: Intermediate
-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).
@@ Line 376: / Line 382: @@
 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.
+The contributor's task here is to write test programs for the OpenPrinting projects libppd and pappl-retrofit 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.
@@ Line 390: / Line 396: @@
 Desired knowledge: C, Shell, PAPPL, CUPS, CI
-Code License: Apache 2.0, MIT
+Code License: Apache 2.0
-=====GNOME Control Center: List and handle IPP print services for the New Architecture=====
-contributor full-size (350 hours).
-Modern printers usually are driverless IPP printers, and those get discovered fully automatically by CUPS, no CUPS queue needs to get explicitly created. Same for remote CUPS printers and also Printer Applications (new format for drivers for non-driverless specialty and legacy printers). They get all discovered as IPP print services.
-This means that a printer setup tool does not need to display CUPS queues any more, but instead, IPP print services, each of them being a possible destination for print jobs.
-And listings of IPP print services have different requirements: One server can have more than one individual print services and these should get listed together. This could be a print queue and a fax out queue of the same multi-function printer, or two physical legacy printers supported by one Printer Application. Also the user interaction coupled to each listing is different. We do not need to configure PPD option settings, but instead, we need access to the IPP service's web administration interface and also to an IPP System Service configuration panel by a simple mouse click.
-Several parts of this got already coded in previous GSoCs, but we need to get everything smoothly integrated in the "Printers" part of the GNOME Control Center, and this is the contributors task here. They will work together with the upstream maintainer of the "Printers" module, Marek Kasik and also with the UI/UX design teams of GNOME and of Canonical.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Mare Kasik (mkasik at redhat dot com), further GNOME/GTK developers TBD
-Desired knowledge: %%C/C++%%, GTK, DNS-SD/Avahi, CUPS/IPP
-Code License: GPL-2+ and LGPL-2+
 =====cups-filters: Create OCR filter to deliver scans as searchable PDFs=====
-contributor half-size (175 hrs)
+contributor half-size (175 hrs), Level of difficulty: Intermediate
 Scanning with IPP Scan gives the user the possibility to request the scanned image in PDF format. If the IPP Scan server is a Scanner Application, a filter function from cups-filters would convert the the raster image coming from the scanner into PDF.

Wiki

User Tools

Site Tools

Differences

Page Tools