Differences

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

--- gsoc:google-summer-code-2025-openprinting-projects [2025/01/15 21:47]
till
+++ gsoc:google-summer-code-2025-openprinting-projects [2025/03/10 11:52] (current)
till [Port CUPS and Printer Applications to Zephyr]
@@ Line 38: / Line 38: @@
   * [[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]]
+====Introduction into deploying OSS/Fuzz====
+  * [[https://www.youtube.com/watch?v=S0IyScIRzb8|Fuzzing in the open: Integrate your project in OSS-Fuzz for continuous fuzzing]] ([[https://events.canonical.com/event/51/contributions/540/attachments/230/529/Presentation.pdf|Slides]], [[https://github.com/iosifache/fuzzingintheopen|Exercises]])
 ====Printer Drivers get Printer Applications====
@@ Line 82: / Line 86: @@
 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 started in GSoC [[https://github.com/Bhavna2020/GSoC-2021|2021]] and continued in GSoC [[https://gist.github.com/Rishabh-792/b1a2960b7e0e3d2bd3a5f4db3d260fc0|2022]] and [[https://dev.to/kappuccino111/sandboxing-scanners-a-leap-into-the-driverless-realm-gsoc-23-report-3eci|2023]].
+Work on extending the Printer Application framework [[https://github.com/michaelrsweet/pappl/|PAPPL]] has already been started in GSoC [[https://github.com/Bhavna2020/GSoC-2021|2021]] and continued in GSoC [[https://gist.github.com/Rishabh-792/b1a2960b7e0e3d2bd3a5f4db3d260fc0|2022]], [[https://dev.to/kappuccino111/sandboxing-scanners-a-leap-into-the-driverless-realm-gsoc-23-report-3eci|2023]], and [[https://dev.to/kappuccino111/pappl-scan-api-bridging-gsoc-2024-project-report-2hoc|2024]].
 ====Desktop Integration====
@@ Line 88: / Line 92: @@
 Most print jobs are created from desktop applications. Users create printable documents with applications like LibreOffice or GIMP, they receive documents by e-mail, want to print web content which they see in their browsers, ... Therefore working support for printing in desktop environments is essentially important.
-There are two types of user interfaces needed. One is the print dialog which pops up when printing out of an application. It allows to choose on which of the available printers to print and to control details of how the content gets printed, like paper type and size, print quality, double-sided printing, ... The second interface is the printer setup tool, for finding and configuring printers to make them available for printing, and to se useful defaults for the most common printing tasks.
+There are two types of user interfaces needed. One is the print dialog which pops up when printing out of an application. It allows to choose on which of the available printers to print and to control details of how the content gets printed, like paper type and size, print quality, double-sided printing, ... The second interface is the printer setup tool, for finding and configuring printers to make them available for printing, and to set useful defaults for the most common printing tasks.
 This functionality is usually available for all desktop environments and applications, but with the New Architecture we need to change it, because print destinations are now defined differently.
@@ Line 98: / Line 102: @@
 For print dialogs we separate the GUI and the communication with CUPS into separate frontend (print dialog) and backend (CUPS communication) using the [[https://openprinting.github.io/achievements/#common-print-dialog-backends|Common Print Dialog Backends]]. So the CUPS backend is maintained by OpenPrinting, as CUPS itself, meaning that it will always keep pace with the development of CUPS, and changes in CUPS, like the New Architecture, will go into it right away. By this we only need to take care that all existing print dialogs (GNOME/GTK, KDE/Qt, Mozilla (Firefox/Thunderbird), Chromium Browser, LibreOffice) get CPDB support.
-Printer setup tools (GNOME Control Center, KDE Settings, system-config-printer) need to list IPP print destinations on their main view, and give appropriate configuration options on them to the user, especially a button to quickly open the web admin interface, also the destinations should get listed in logical groups,to have printing and fax out of a multi-function device together, or the printers supported by the same Printer Application.
+Printer setup tools (GNOME Control Center, KDE Settings, system-config-printer) need to list IPP print destinations on their main view, and give appropriate configuration options on them to the user, especially a button to quickly open the web admin interface, also the destinations should get listed in logical groups, to have printing and fax out of a multi-function device together, or the printers supported by the same Printer Application.
-Also the "Add Printer" part of the printer setup tools still makes sense.It has to list non-driverless printers and assign Printer Applications instead of PPD files to them.
+Also the "Add Printer" part of the printer setup tools still makes sense. It has to list non-driverless printers and assign Printer Applications instead of PPD files to them.
-Actually we will not remove the old functionality from the printer setup tools and replace it by the new on. Instead, we add the new functionality so that the tool works with any CUPS version, and in the case of CUPS 2.x they will then handle both permanent CUPS queues with PPD files and IPP print destinations which CUPS can print on without needing to create a queue. This way distributions will be able to switch to CUPS 3.x at any time and no synchronous switch of both CUPS and the printer setup tool(s) is required.
+Actually we will not remove the old functionality from the printer setup tools and replace it by the new one. Instead, we add the new functionality so that the tool works with any CUPS version, and in the case of CUPS 2.x they will then handle both permanent CUPS queues with PPD files and IPP print destinations which CUPS can print on without needing to create a queue. This way distributions will be able to switch to CUPS 3.x at any time and no synchronous switch of both CUPS and the printer setup tool(s) is required.
-Parts of this work got already done, especially most of the "Printers" module in GNOME Control Center by Mohit Verma during GSoC [[https://github.com/vermamohit13/GSOC_2022_Summary|2022]] and [[https://github.com/vermamohit13/GSOC-2023|2023]], CPDB support in the GTK print dialog and most of the CPDB support in the Qt print dialog by Gaurav Guleria in GSoC [[https://github.com/TinyTrebuchet/gsoc22/|2022]] and CPDB support for the print dialog of the Chromium Browser by Kushagra Sharma in GSoC [[https://github.com/kushagra20251/GSoC/|2023]].
+Parts of this work got already done, especially most of the "Printers" module in GNOME Control Center by Mohit Verma during GSoC [[https://github.com/vermamohit13/GSOC_2022_Summary|2022]] and [[https://github.com/vermamohit13/GSOC-2023|2023]] and by Kaushik Vishwakarma in GSoC [[https://medium.com/@kaushik.vishwakarma2003/gsoc-2024-thelinuxfoundation-journey-07e24d7e9be9|2024]], CPDB support in the GTK print dialog and most of the CPDB support in the Qt print dialog by Gaurav Guleria in GSoC [[https://github.com/TinyTrebuchet/gsoc22/|2022]], CPDB support for the print dialog of the Chromium Browser by Kushagra Sharma in GSoC [[https://github.com/kushagra20251/GSoC/|2023]], for the Mozilla (Thunderbird and Firefox) print dialog also by Kushagra Sharma in GSoC [[https://github.com/kushagra20251/GSoC24|2024]], and for the LibreOffice print dialog by Biswadeep Purkayastha in GSoC [[https://medium.com/@bpdps95/providing-cpdb-support-for-the-libreoffice-print-dialog-my-gsoc-journey-e46f72d5a61c|2024]]. Biswadeep and his mentor, Michael Weghorn also contributed a lot to [[https://openprinting.github.io/OpenPrinting-News-July-2024/#pull-requests|CPDB itself]]. In addition, we have a volunteer, Tarun Srivastava, working on the [[https://openprinting.github.io/OpenPrinting-News-June-2024/#kde-print-manager|KDE Print Manager]].
 For a smooth transition to CUPS 3.x in all distributions we need to add support for the New Architecture in **all** desktop environments and **all** applications. Especially if we want to switch Ubuntu to CUPS 3.x we cannot only take GNOME into account, as the core of the Ubuntu distribution is also used by the 10 official, community-maintained flavors which cover a wide range of desktops. Therefore we were [[https://openprinting.github.io/OpenPrinting-News-August-2023/#the-cups-snap-not-in-ubuntu-2310|not able to switch Ubuntu 23.10 to use the CUPS Snap]].
 ====What we are currently doing at OpenPrinting====
@@ Line 140: / Line 143: @@
 ======Project Ideas======
-**TO BE UPDATED**
+NOTE: Further project ideas can get added at any time before the contributor application deadline. The already listed project ideas can get updated, like correcting mistakes and completing information, like the mentor lists.
-=====Desktop integration: CPDB support for the print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice=====
+So please have a look here from time to time ...
--2 contributors full-size (350 hours), Level of difficulty: Hard
+=====Qt Print Dialog: Modernize the user interface=====
-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.
+contributor full-size (350 hours), Level of difficulty: Hard
-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.
+The print dialog of [[https://contribute.qt-project.org/|Qt]], which is also the print dialog used by KDE applications has still the user interface of 20 years ago, when I told the Qt and KDE developers that a CUPS-supporting print dialog is needed and they made this print dialog in response.
-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.
+Now, after the internals of the dialog being up-to-date (Support for the [[https://openprinting.github.io/achievements/#common-print-dialog-backends|Common Print Dialog Backends]] added in [[https://github.com/TinyTrebuchet/gsoc22/|GSoC 2022]]) we need to make the user interface of the Qt print dialog cute.
-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.
+The modernization should at least be a UI similar to the one of the GTK print dioalog. This should not require any extensions of the API between the print dialog and the applications and so the new dialog can replace the old one without modifications on existing applications needed.
-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.
+Optionally, depending on the time left, a dialog with built-in preview (Like in LibreOffice, Chromium, Firefox, Thunderbird) could be created. This requires more UI design work and most probably also additions to the API. The migration of a simple application (like text editor or document viewer) to the new print dialog would demo it and  make the developers of other applications switch over.
-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.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Qt developers, TBD
-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.
+Desired knowledge: %%C/C++%%, Qt, UI Design
-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).
+Code License: LGPL-3 and GPL-2
-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, ...).
+=====GTK Print Dialog: Modern dialog with built-in preview in main view=====
-CPDB support for the print dialog of the Chromium Browser is already done by Kushagra Sharma in GSoC [[https://github.com/kushagra20251/GSoC/|2023]].
+contributor full-size (350 hours), Level of difficulty: Hard
-For the CPDB integration we do not need UI design work.
+Are you using LibreOffice, Firefox, Thunderbird, or Chromium with their nice, modern preview-centric print dialogs and got somewhat disappointed with GNOME apps like the Text Editor, Evince, or similar because of their more conventional [[https://gitlab.gnome.org/GNOME/gtk|GTK]] print dialog? Note that GTK's dialog has also a preview, but it is awkward to use, one has to click a button to get a preview, but there is no button to return to the main dialog to do adjustments.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Firefox/Thunderbird/Mozilla developers, LibreOffice developers, TBD
+Then you should make an end to this problem, by modernizing the user interface (UI) of GTK's print dialog!
-Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
+Investigate the workflow of the modern preview-centric print dialogs and also have a look into their code (the mentioned apps are all open source). Also have a look into the code base of GTK's print dialog. Then design a similar UI, with embedded preview for the print dialog and implement it in GTK.
-Code License: MIT, GPL-2+ and LGPL-2+
+Try to conserve the API between the application and the print dialog, so that the new print dialog can just replace old one in all applications. If this is not possible, try to keep the API additions a minimum, and for applications which are not (yet) adapted to the new print dialog, try to make as much as possible working in your print dialog (and as last resort display the old dialog).
-=====Desktop Integration: Update system-config-printer for the New Architecture of printing=====
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GTK/GNOME developers, TBD
-contributor full-size (350 hours), Level of difficulty: Intermediate
+Desired knowledge: C, GTK/GNOME, UI Design
-Originally, we already had discontinued the development of system-config-printer and put it into maintenance mode, only fixing bugs and collecting UI translations.
+Code License: LGPL-2 or later and LGPL-2.1 or later
-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.
+=====KDE Print Manager vs. CUPS 3.x=====
-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.
+contributor full-size (350 hours), Level of difficulty: Hard
-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.
+As we have made the "Printers" module of the GNOME Control Center supporting CUPS 3.x in several GSoC projects we need to do the same for the [[https://invent.kde.org/plasma/print-manager/|KDE Print Manger]]. And this is what this project is about.
-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.
+For the local server of CUPS 3.x the main view does not need to display CUPS queues as defined in `/etc/cups/printers.conf` with PPD files any more but instead, it has to display IPP print destinations (driverless network and IPP-over-USB printers, Printer Applications, shared remote CUPS queues) as on all these we can print, without a CUPS queue needing to be created, as CUPS creates a temporary one when needed. The destinations have to be grouped, when they come from the same device, server, or Printer Application, and the IPP destinations are configured by their admin web interfaces, so we have to add buttons to open these interfaces.
-And this is the contributor's task in this project.
+The "Add Printer" dialog will continue to exist, but to list non-driverless (legacy or specialty) printers and assign Printer Applications instead of PPD files to them.
-Note that system-config-printer is written in Python.
+Actually we will only add the new functionality and not remove the old one, meaning displaying both IPP destinations and classic CUPS queues, and in the "Add Printer" part allow for assigning both PPD files and Printer Applications (latter preferred), so that once the new Print Manager in place we can make a smooth transition from CUPS 2.x to CUPS 3.x at any time, and also, CUPS 2.x already supports IPP print destinations without permanent CUPS queue, so also for CUPS 2.x users modern, driverless printers will just appear and they do not try to unecessarily create queues for them.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Mike Noe (noeerover at gmail dot com), KDE developers, TBD
+Desired knowledge: %%C/C++%%, KDE/Qt, UI Design
+Code License: GPL 2.0 or later and LGPL 2.0 or later
+=====Port pyCUPS to CUPS 3.x API + Apply the new pyCUPS to system-config-printer=====
+contributor full-size (350 hours), Level of difficulty: Intermediate
+Most software with print functionality or print administration functionality uses the CUPS library (libcups, [[https://github.com/OpenPrinting/cups/|2.x]], [[https://github.com/OpenPrinting/libcups/|3.x]]) to communicate with CUPS. This is easy when the software is written in C or %%C++%% as the library is written in C.
+If the software is written in other languages, we need some connection between the library and the client code, the so-called bindings. For Python we have bindings for libcups, [[https://github.com/OpenPrinting/pycups|pyCUPS]]. This works well with libcups 2.x already for years. [[https://github.com/OpenPrinting/system-config-printer|system-config-printer]] is principal user of pyCUPS.
+What we need now is to extend pyCUPS for the use with [[https://github.com/OpenPrinting/libcups/|libcups 3.x]] of the new [[https://openprinting.github.io/cups/cups3.html|CUPS 3.x]], so that pyCUPS will live on and continue to allow writing software which interacts with CUPS in Python.
+The contributor's task is to go through the APIs of libcups3 and compare them with libcups2 to see what has to be added. If there is a way to automate the creation of Python bindings, it can be used and old (libcups2) and new (libcups3) has to be merged, so that pyCUPS can be used for any version of libcups.
+It should be also taken into account that libcups2 of CUPS 2.5.x got some functions of libcups3 backported.
+system-config-printer was already updated for CUPS 3.x in [[https://github.com/TheJayas/GSoC-2024-Final-Report|last year's GSoC]]. Here we want system-config-printer use the new pyCUPS now, for optimization and minimization of code duplication.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Zdenek Dohnal, Printing Maintainer at Red Hat (zdohnal at redhat dot com), TBD
 Desired knowledge: Python, C, CUPS
@@ Line 198: / Line 223: @@
 Code License: GPL-2+ (GPL 2 or any later version)
-=====Desktop Integration: User interfaces for using OAuth2 with printers and scanners=====
+=====Extend PDFio to be a PDF renderer/displayer=====
 contributor full-size (350 hours), Level of difficulty: Hard
-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).
+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++%%.
-Authorization in printing is needed to once protect the data of confidential jobs, and second, to protect printer resources, like toner or paper.
+In libcupsfilters we now succeeded to eliminate use of %%C++%%, by replacing the use of the %%C++%% library [[https://github.com/qpdf/qpdf/|QPDF]] for PDF manipulation by Michael Sweet's [[https://www.msweet.org/pdfio/|PDFio]] and also by not using libpoppler any more but using Poppler's command line utilities instead. This was done as a [[https://medium.com/@uddhavphatak/gsoc-2024-final-report-the-refactor-report-a46756e9d6ce|GSoC project last year]].
-OAuth2, standard for authorization for internet services ("Log in with Google") is also used as authorization standard for IPP (Internet Printing Protocol) printing.
+As the call of Poppler via command line utilities and Ghostscript having a license which makes it unsuitable in vertain cases, we are looking into a PDF rasterizer which is written in straight C and has a more friendly (permissive) license. PDFio is written in C and has the same license as CUPS and libcupsfilters themselves, but it is only a PDF manipulation library, not a renderer.
-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.
+But as PDFio is able to do the "dirty work" of PDF file reading, especially navigating through the file's object structure we can make use of it to create a PDF renderer, ideally to extend the PDFio library to provide this functionality or to create the renderer library using PDFio.
-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.
+This renderer should be aimed for printing, it should be principally called from libcupsfilters, or from Printer Applications, so the goal of this project is to get in this direction and not design a fancy GUI document viewer, but a simple screen display facility would be helpful for development and debugging.
-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.
+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
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), TBD
+Desired knowledge: %%C/C++%%, CUPS
-Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
+Code License: Apache 2.0
-Code License: Apache 2.0, MIT, GPL-2+ and LGPL-2+
+=====Utilizing OSS-Fuzz-Gen to Improve Fuzz Testing for OpenPrinting Projects=====
-=====Integrating C-based OpenPrinting projects in OSS-Fuzz testing=====
+**Security- and AI-related project**
-contributor full-size (350 hours), Level of difficulty: Intermediate
+contributor full-size (350 hours), Level of difficulty: Hard
-[[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.
+Recent vulnerabilities (including [[https://openprinting.github.io/OpenPrinting-News-Flash-cups-browsed-Remote-Code-Execution-vulnerability/|CVE-2024-47175, CVE-2024-47176, CVE-2024-47177]]) reported in OpenPrinting projects have underscored the critical need for robust security measures. Given that most of the projects of OpenPrinting are developed in %%C/C++%%, which are prone to memory violation bugs. To address these challenges, OpenPrinting has engaged with Google's [[https://github.com/google/oss-fuzz/|OSS-Fuzz]], a service designed to support open-source communities by providing large-scale fuzz testing and bug reporting, and maintains the fuzz harnesses in the separate [[https://github.com/OpenPrinting/fuzzing|OpenPrinting fuzzing]] repository.
-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.
+**Current Integration with OSS-Fuzz:** OpenPrinting has successfully integrated **three** key projects into the OSS-Fuzz workflow, with **two** additional projects currently in progress. Although the integration has already yielded significant results, which have reported **21** critical fixed bugs leading to more than **5,000** lines of code fixes, it remains insufficient. The [[https://introspector.oss-fuzz.com/project-profile?project=cups|testing coverage]] for critical components is still lacking, and the severity of potential issues within OpenPrinting projects demands further action.
-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):
+For now, OpenPrinting has integrated projects into the OSS-Fuzz workflow:
+  * [[https://github.com/OpenPrinting/cups|cups]]
+  * [[https://github.com/OpenPrinting/libcups|libcups (of CUPS 3.x)]]
+  * [[https://github.com/OpenPrinting/cups-filters|cups-filters]]
-  * CUPS
+The following projects are under construction:
-  * libcups
+  * [[https://github.com/OpenPrinting/libcupsfilters|libcupsfilters]]
-  * cups-local
+  * [[https://github.com/OpenPrinting/cups-browsed|cups-browsed]]
-  * cups-sharing
-  * libcupsfilters
-  * cups-filters
-  * cups-browsed
-  * PAPPL
-  * cpdb-libs
-  * cpdb-backend-cups
-  * libppd
-  * pappl-retrofit
-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.
+With Google's introduction of [[https://github.com/google/oss-fuzz-gen|OSS-Fuzz-Gen]], which leverages Large Language Models (LLMs) to enhance fuzz testing for open-source software, it has demonstrated exceptional potential in facilitating the integration of high-quality fuzz testing ([[https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html|Google Blog]]). Therefore, we aim to utilize the OSS-Fuzz-Gen framework to further improve the existing quality of OSS-Fuzz harnesses
-The contributor should work on:
+**Project Goals for GSoC 2025:** The primary objective for this Google Summer of Code project is to refine and expand our existing fuzz testing harnesses. Specifically:
+  * **Enhancing Existing Harnesses:** Improve the quality of dictionaries, configurations, and seed data for current integrations, adhering to OSS-Fuzz best practices.
+  * **Expanding Harness Integration:** Utilize OSS-Fuzz-Gen to develop and implement additional harnesses, targeting high-value, difficult-to-reach code sections with the support of LLMs.
-  * Coordinating with OpenPrinting which projects have highest priority and also which functionality of them, to get the best from the limited GSoC time
+**Contributor Responsibilities:**
-  * Creating Docker-based build environments
+  * Master OSS-Fuzz best practices to provide high-quality seeds and corpus for existing integrations. Employ OSS-Fuzz-Gen to create and integrate new harnesses, adopting diverse strategies to enhance code coverage.
-  * Writing libFuzzer fuzz targets
+  * Collaborate with OpenPrinting developers to identify and patch vulnerabilities uncovered through fuzz testing.
-  * 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.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
-Desired knowledge: C, fuzzing
+Desired knowledge: C, Python, fuzz-testing
 Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
-=====Official OCI containers (Docker, ROCKs, podman, ...) of CUPS and Printer Applications=====
+=====Integrating OSS-Fuzz for Go-Based and Python-Based OpenPrinting Projects=====
-contributor full-size (350 hours), Level of difficulty: Intermediate
-[[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.
-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.
+**Security-related project**
-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.
+contributor medium-size (175 hours), Level of difficulty: Intermediate
-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.
+OpenPrinting hosts many polyglot projects, which are developed not limited to languages of %%C/C++%%. We also host software written in languages like Python and Golang, which function as crucial printing APIs and often interface with %%C/C++%% libraries to deliver comprehensive printing services. The integration of multiple programming languages into our ecosystem underscores the necessity for a broad and inclusive testing approach. Given the diversity of development environments, it is crucial to extend the testing for these projects, specifically for integration of [[https://github.com/google/oss-fuzz|OSS-Fuzz]].
-Another point is how to add printer and scanner drivers to immutable distributions. For this we also need containers of Printer and Scanner Applications.
+To this end, we plan to extend the capabilities of the existing OSS-Fuzz frameworks to include projects developed in languages other than %%C/C++%%. This initiative will target Python and Golang projects, ensuring that our fuzz testing encompasses the full spectrum of development environments within OpenPrinting.
-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.
+**Project Goals for GSoC 2025:** The primary objective for this Google Summer of Code project is to integrate the polyglot projects in OpenPrinting into OSS-Fuzz framework and refine existing unit tests for these projects. The targeting projects include:
+  * **Golang**
+    * [[https://github.com/OpenPrinting/ipp-usb|ipp-usb]]
+    * [[https://github.com/OpenPrinting/goipp|goipp]]
+  * **Python**
+    * [[https://github.com/OpenPrinting/pycups|pycups]]
+    * [[https://github.com/OpenPrinting/pyppd|pyppd]]
+**Contributor Responsibilities:**
+  * **Evaluate and Improve Testing Approaches:** The contributor needs to understand existing testing strategies within the project and evaluate their effectiveness. Where there are gaps, particularly in areas that are under-tested, the contributor should develop and improve tests to cover these functionalities.
+  * **Integrate Projects into OSS-Fuzz Workflow:** The contributor should also integrate these projects into OSS-Fuzz framework, following previous integrations for %%C/C++%% projects in OpenPrinting [[https://github.com/OpenPrinting/fuzzing|fuzzing]] repository with appropriate fuzzing corpus.
+  * **Triage and Report Vulnerabilities:** The contributor should work closely with developers from OpenPrinting to identify and report any vulnerabilities that are discovered through the testing process.
-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.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
-Desired knowledge: Shell, Python, packaging, immutable OS distributions, GIT
+Desired knowledge: Python, Go, fuzz-testing
 Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
-=====Replace QPDF by PDFio as PDF manipulation library in libcupsfilters (cfFilterPDFToPDF() filter function and others)=====
+=====System/Fuzz Testing of Printing Protocols=====
+**Security-related project**
 contributor full-size (350 hours), Level of difficulty: Hard
-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++%%.
+As OpenPrinting advances driverless printing services, the corresponding standardized printing protocols, such as the Internet Printing Protocol (IPP), have become more and more important. The protocol is fundamental to achieving generalized printing services and thus requires rigorous security testing to prevent vulnerabilities.
-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().
+Effective testing of printing protocols and Domain-specific languages (DSL) like IPP and PostScript demands precise input pairs and well-regulated testing environments/contexts. Given the complexity and technical specifications of these protocols, creating universal testing suites that can be applied across various platforms and languages is essential. Such suites will support the consistent functionality and specification adherence necessary for secure and efficient printing operations.
-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++%%.
+**Project Goals for GSoC 2025:** The primary objective for this Google Summer of Code project is to develop comprehensive testing suites designed for the printing protocols used in OpenPrinting projects (e.g., IPP). Specifically, the suites encompass: (1) unit tests and differential tests for IPP, detailing test inputs and expected outputs within the appropriate printing contexts, and (2) fuzzing enhanced by a custom validator to verify the correctness of outputs against the specifications. These suites will incorporate unified testing drivers and oracles (validated test input and output pairs) to ensure accurate and reliable results.
-Therefore we want to replace the use of QPDF by PDFio and this is what this GSoC project is about.
+**Contributors are expected to achieve:**
+  * Thoroughly understand and summarize the key aspects of printing protocols used in OpenPrinting, such as IPP and PostScript.
+  * Develop tailored testing strategies for these protocols, referencing standards such as [[https://datatracker.ietf.org/doc/html/rfc8011|RFC 8011]], and [[https://openprinting.github.io/cups/doc/spec-ipp.html|OpenPrinting's 17 IPP specifications]]
+  * Implement high-quality unit tests, differential tests, and fuzzing drivers along with protocol-tailed testing oracles within OpenPrinting projects. Contributors will also be responsible for identifying any discrepancies or bugs, reporting them, and coordinating with developers to facilitate necessary fixes.
-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.
+//The outputs of this project will not only serve as a valuable reference for generalizing testing across all OpenPrinting projects but also the documented progress can also lead to potential academic contributions, such as technical reports or research papers.//
-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), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
-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++%%, security/testing
-Desired knowledge: %%C/C++%%, CUPS
+Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
-Code License: Apache 2.0
+=====Security Auditing for OpenPrinting Projects=====
-=====Turn cups-browsed into a Printer Application=====
+**Security-related project**
 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.
+OpenPrinting projects play a critical role in the printing infrastructure of countless systems, making their security paramount. Inspired by security auditing reports from other open source communities (CNCF: [[https://www.cncf.io/blog/2025/01/16/announcing-the-results-of-the-karmada-security-audit/|Security Audit for Karmada]], [[https://www.cncf.io/blog/2023/04/19/new-kubernetes-security-audit-complete-and-open-sourced/|Security Audit for Kubernetes]] and [[https://openssf.org/blog/2023/02/01/independent-security-audit-impact-report/|Security Audit for OpenSSF]]), we believe a comprehensive security auditing report could significantly enhance the robustness and reliability of these projects. This initiative will leverage advanced software analysis methods to conduct thorough security audits.
-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.
+The audit process includes scoring OpenPrinting projects using OpenSSF’s Security Scorecard and examining the projects and their dependencies with respect to testing status, which encompasses adherence to continuous integration (CI) test best practices and test coverage assessments. Furthermore, dynamic testing should also be considered, for example, end-to-end fuzzing techniques such as [[https://github.com/AFLplusplus/AFLplusplus|AFLplusplus]], which assists in the successful detection of [[https://www.cve.org/CVERecord?id=CVE-2024-47076|CVE-2024-47076]]. Static analysis tools including [[https://github.com/danmar/cppcheck|cppcheck]] and [[https://github.com/david-a-wheeler/flawfinder|flawfinder]], [[https://valgrind.org/|Valgrind]] can be employed for checking the implementation flaws. The overall security audit should include dynamic software analysis methodologies to cover more extensive aspects of OpenPrinting projects.
-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.
+**Project Goals for GSoC 2025:** The primary objective of this Google Summer of Code project is to complete a systematic security audit report for OpenPrinting. This comprehensive process includes maximizing the scores provided by the [[https://scorecard.dev|OpenSSF Security Scorecard]] and scanning dependencies using existing SADT tools. In addition to static analysis, incorporating dynamic testing methodologies will provide an exhaustive overview of security across the entire network of projects. The project aims to identify and mitigate potential vulnerabilities effectively, ensuring that a robust defense mechanism is in place to protect the integrity of the OpenPrinting infrastructure.
-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.
+**Contributors are expected to:** Use or implement dynamic testing/auditing tools for analyzing OpenPrinting projects, which includes examining OpenSSF Scorecard of OpenPrinting projects and preparing detailed security auditing reports outlining discovered vulnerabilities. The contributor should also coordinate with security experts to address these issues effectively.
-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, ...
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
-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.
+Desired knowledge: %%C/C++%%, code auditing
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Deepak Patankar (patankardeepak04 at gmail dot com), TBD
+Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
-Desired knowledge: %%C%%, CUPS
+=====Behavior-accurate simulation of multi-function printers (printer + scanner)=====
-Code License: Apache 2.0
+-3 contributors full-size (350 hours), Level of difficulty: Hard
+Although driverless printing and scanning are governed by standards and specifications, real hardware implementations often have unique details that can deviate from these specifications, impacting the accuracy of our printing and scanning implementations.
+We currently have the "ippeveprinter" tool, which implements an "abstract" IPP 2.x printer. However, we lack a behavior-accurate simulation of real printers and do not have any simulation for eSCL/WSD scanners.
+The goal is to create a behavior-accurate simulator for multi-function printers (MFPs) that supports at least IPP 2.x for printing, eSCL and WSD for scanning, and DNS-SD and WS-Discovery for device discovery. We aim to build a growing collection of models representing various specific devices.
+This simulator will consist of a core simulation engine that provides reference implementations of the aforementioned protocols, along with a customization engine that allows for the expression of implementation details specific to individual devices without the need to reimplement common functionalities repeatedly.
+One of our key objectives is to make the process of creating MFP models semi-automated. For instance, printer attributes and scanner capabilities can be automatically obtained, while accurately simulating behavioral features may require manual testing and analysis to identify these details, along with scripting to express them in the simulator. We anticipate that actual device behavior will not deviate significantly from the "ideal" model implemented by the simulation core, allowing models to remain relatively straightforward. Ideally, the model creation process should be simple enough for mid-level technical personnel and qualified users to undertake independently.
+This initiative opens up several new avenues:
+  * Remote debugging of printing/scanning issues without needing to connect to the device or engage extensively with the device owner
+  * The ability to test software changes without physical access to the relevant hardware
+  * Full-stack automated testing of printing and scanning against simulated hardware
+Initially, our collection of models will be small and may contain inaccuracies. However, as we expand our model collection, we will be able to automatically detect most regression cases during the development of the entire printing and scanning stack.
+The implementation of the simulation core has already started, what we need from the contributor(s) is to develop the initial collection of the printer models. During this phase, we will evaluate and refine the overall concept, establishing and assessing the methodology for creating MFP models.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
+Desired knowledge: Familiarity with relevant protocols (IPP, eSCL, WSD, DNS-SD), knowledge of the Linux printing and scanning stack, programming in C, and proficiency in Python or JavaScript (for scripting MFP models).
+Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
-=====Converting Braille embosser support into a Printer Application=====
+=====Image output evaluation for testing of print/scan job processing=====
 contributor full-size (350 hours), Level of difficulty: Hard
-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.
+We do a lot of testing for quality assurance and security of our software, especially also tests of the data processing when printing and scanning. For now our only criteria to consider a test failed is a processing error, a crash, an infinite loop, or the output being empty. We do not verify whether the content of the output is actually what we have expected.
-For long-term support and wide availability, this needs to be converted to the newer CUPS infrastructure, Printer Applications.
+Evaluating the correctness of the content of the output is not easy, as we cannot compare it pixel by pixel, we rather need to determine whether a human being would see the content which they have sent to the printer. This means to recognize text, structures, colors, but with a certain tolerance.
-The contributor's task is thus:
+There is free software work at GNOME for the CI testing of their GUI, which requires to analyse graphical screen content to evaluate whether the response of GUI apps to given user input is as expected, and this should be fully automated. This is the [[https://gitlab.gnome.org/GNOME/openqa-tests|openQA]] project.
-  * Converting these shell scripts into filter functions in libcupsfilters
+To compare graphical content they use the free software computer vision library [[https://opencv.org/|OpenCV]] and also the universal file comparison tool [[https://diffoscope.org/|diffoscope]] is used to check output.
-  * Creating a Printer Application that exposes Braille embossers configuration to users
-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.
+With this we could for example take a PDF file, rasterize it in high quality, then "print" it/send it through a filter chain and afterwards compare the images. We can also OCR raster output to check whether the complete text of the input (plain text or PDF file) is conserved in the output, not having anything cut off at the borders and no glyphs missing or replaced by squares/placeholders for missing glyphs.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Samuel Thibault, Braille expert (samuel dot thibault at ens-lyon dot org)
+See also [[https://openprinting.github.io/OpenPrinting-News-July-2024/#guadec-2024-in-denver|my report from the GUADEC 2024]], the section "Workshop: openQA testing for your GNOME app, module or service".
-Desired knowledge: %%C/C++%%, Shell, CUPS
+Tests which benefit from this are not only our CI testing in libcupsfilters, but also 2 of our other projects on this list:
+  * Behavior-accurate simulation of multi-function printers
+  * Fuzz-based testing of printing protocols
-Code License: Apache 2.0
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
-=====Make a native Printer Application from Gutenprint=====
+Desired knowledge: C, Go, image processing and evaluation, computer vision, OCR
+Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
+=====Port CUPS and Printer Applications to Zephyr=====
+Probably many of you have already thought about that one can take an SBC, install Linux and [[https://openprinting.github.io/cups|CUPS]] or a Printer Application on it, and connect this to an old printer which is still mechanically perfect but needs a driver which is not available any more for some operating systems. Suddenly the printer turns into a modern, driverless IPP printer which can be used with any operating system.
+But it is a little awkward having a little box dangling behind the printer which also occupies a power outlet. Also one can perhaps also make use of much cheaper SBC.
+Imagine you could buy a tiny board for a few dollars and put it somewhere inside the printer and grab its power from the printer's power supply.
+Such tiny boards are often not powerful enough to run Linux, but there is also the much more lightweight [[https://www.zephyrproject.org/|Zephyr]] operating system. This is a system for IoT applications on low-footprint hardware.
+And this scenario does not only serve for cheap DIY solutions to save old printers, it also can be a base for cost-effective printer firmware development.
+This project is about investigating whether one could run the components of the free software printing stack, as [[https://openprinting.github.io/cups|CUPS]], [[https://github.com/michaelrsweet/pappl/|PAPPL]], [[https://github.com/OpenPrinting/libcupsfilters|libcupsfilters]], ... under the Zephyr operating system, and actually let this tiny print server execute printer drivers and print on legacy printers. Also the handling of print data and the need of resources here needs to be investigated. Can we hold several pages? Can we use [[https://ghostscript.com/|Ghostscript]]? Or do we have to stream raster print data from the client to the printer?
+Most desirable is to do this with PAPPL (Printer APPlication Library), as it is designed to emulate a driverless IPP printer in software, including the so-called "Gadget" mode to appear as an IPP-over-USB device when connecting the power supply USB port of the SBC with the client computer's USB.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Iuliana Prodan (iuliana dot prodan at nxp dot com), Zephyr developers TBD
+Desired knowledge: C, Zephyr, USB, network
+Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
+=====Rust bindings for libcups2/3=====
 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.
+Most software with print functionality or print administration functionality uses the CUPS library (libcups, [[https://github.com/OpenPrinting/cups/|2.x]], [[https://github.com/OpenPrinting/libcups/|3.x]]) to communicate with CUPS. This is easy when the software is written in C or %%C++%% as the library is written in C. If the software is written in other languages, we need some connection between the library and the client code, the so-called bindings.
-Gutenprint is usually used as classic CUPS driver with a CUPS filter and a PPD file generator. As, as mentioned above, CUPS will not support PPD files any more from version 3.x on and when using the CUPS Snap one cannot install PPD-based drivers already now.
+A programming language which gets more and more used nowadays is Rust, due to its memory-safety, eliminating the number-one source of crashes and vulnerabilities. Unfortunately, we do not have Rust bindings for libcups. And getting them is subject of this project.
-So a Printer Application of Gutenprint is needed. There [[https://github.com/OpenPrinting/gutenprint-printer-app/|is already one]], but it is a retro-fit of the classic CUPS driver. The Printer Application simply calls the PPD generator and the filter at the right places to do its job.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
-As Gutenprint contains all its printer support and printer capability info in libgutenprint or in files which are read by libgutenprint, the PPD generator and the filter only containing calls of functions in libgutenprint, it should be easy to create a [[https://github.com/michaelrsweet/pappl/|PAPPL-based]], native Printer Application for Gutenprint.
+Desired knowledge: Python, C, CUPS
-Here on an incoming get-printer-attributes IPP request we call the same functions which the PPD generator calls, but instead of translating the responses into a PPD file we translate it into the IPP answer for the get-printer-attributes request. And when we have a job to print, we call the library functions which the filter calls, but directly.
+Code License: GPL-2+ (GPL 2 or any later version)
-This does not only save us from resource-consuming calls of external executables but we are also no harnessed by the PPD file syntax and so have more flexibility in the UI representations of the (often more than 100) printer-specific options. Also, generally we should completely do away with the PPDs. Retro-fitting is only an ugly interim solution or for drivers which are not actively maintained anymore and for printers we do not have at hand and so cannot test the drivers.
+=====Error response pop-up support for CPDB=====
-The contributor's task is thus:
+ contributor medium-size (175 hours), Level of difficulty: Intermediate
-  * Create a PAPPL-based Printer Application using the libgutenprint library and PAPPL
+It often happens that a print job, sent to a network printer or to a remote CUPS queue does not get printed and [[https://github.com/OpenPrinting/cups/issues/1072|a "cups-pki-invalid" error will get logged]]. This is due to the fact that the locally saved certificate does not match the printer (any more).
-  * Make sure all options and parameters of the Gutenprint driver are accessible from the Printer Application's web admin interface.
-  * Package the Printer Application as a Snap
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gutenprint developers TBD
+To prevent man-in-the-middle attacks between a client and a network IPP printer with encrypted connection, the first time when a new network printer is accessed, the printer's certificate is loaded from the printer and saved locally. On subsequent accesses the printer's certificate is compared to the locally saved one and on mismatch the error is logged and the printing does not happen.
-Desired knowledge: %%C%%, PAPPL, CUPS
+often this happens without an attack, just on a change of the printer configuration or a printer firmware update. Then the user screams on internet platforms, when they are lucky finds information about this problem and how to remove the old certificate to make the CUPS replace it by the current one and the printer print again.
-Code License: Apache 2.0
+To solve this nasty problem, we came to the conclusion to [[https://github.com/OpenPrinting/cups/issues/1072#issuecomment-2537216779|pop up a dialog which allows to remove the certificate file ("Reset certificte") by clicking a button.]].
+The contributor's task here is to create such a dialog and make it pop up in the right situation. The pop-up should also be used for other common error scenarios which could be solved by a simple dialog.
+The communication between the pop-up and CUPS should be done by the [[https://github.com/OpenPrinting/cpdb-libs|Common Print Dialog Backends (CPDB)]], extending the D-Bus interface and implementing the error handling in the CPDB CUPS backend.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Kushagra Sharma (b20251 at students dot iitmandi dot ac dot in), TBD
+Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
+Code License: MIT, GPL-2+ and LGPL-2+
 =====CI Testing programs for libpappl-retrofit and libppd=====
@@ Line 404: / Line 493: @@
 =====cups-filters: Create OCR filter to deliver scans as searchable PDFs=====
-contributor half-size (175 hrs), Level of difficulty: Intermediate
+contributor medium-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