Differences

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

--- gsoc:google-summer-code-2024-openprinting-projects [2024/01/20 02:59]
till
+++ gsoc:google-summer-code-2024-openprinting-projects [2024/01/22 21:42]
till [Desktop Integration: Update system-config-printer for the New Architecture of printing]
@@ Line 7: / Line 7: @@
 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]])
+Telegram: [[https://t.me/+RizBbjXz4uU2ZWM1|OpenPrinting Channel]]
+Mastodon/Fediverse: [[https://ubuntu.social/tags/OpenPrinting|#OpenPrinting]]
 IRC: #openprinting on [[https://libera.chat/|Libera.Chat]]
@@ Line 117: / Line 121: @@
   * [[https://github.com/OpenPrinting/ghostscript-printer-app/|Ghostscript Printer Application]] - Printer Application for printers using Ghostscript (and many other) drivers ([[https://snapcraft.io/ghostscript-printer-app|in the Snap Store]])
   * [[https://github.com/OpenPrinting/hplip-printer-app/|HPLIP Printer Application]] - Printer Application for most HP Printers ([[https://snapcraft.io/hplip-printer-app|in the Snap Store]])
-  * [[https://github.com/OpenPrinting/gutenprint-printer-app/|Gutenprint Printer Application]] - Printer Application for hig-quality printing on Epson, Canon, and other inkjets and on many dye-sublimation printers ([[https://snapcraft.io/gutenprint-printer-app|in the Snap Store]])
+  * [[https://github.com/OpenPrinting/gutenprint-printer-app/|Gutenprint Printer Application]] - Printer Application for high-quality printing on Epson, Canon, and other inkjets and on many dye-sublimation printers ([[https://snapcraft.io/gutenprint-printer-app|in the Snap Store]])
   * [[https://github.com/michaelrsweet/lprint/|LPrint]] - Printer Application for label printers ([[https://snapcraft.io/lprint|in the Snap Store]])
   * [[https://github.com/alexpevzner/sane-airscan/|sane-airscan]] - The "airscan" SANE backend, supports driverless eSCL and WSD scanning, IPP Scan support is planned
@@ Line 134: / Line 138: @@
 =====Desktop integration: CPDB support for the print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice=====
-=====Desktop Integration: Update system-config-printer for the New Architecture of printing=====
+-2 contributors full-size (350 hours).
-=====Desktop Integration: User interfaces for using OAuth2 with printers and scanners=====
+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.
-=====Replace QPDF by PDFio as PDF manipulation library in libcupsfilters (cfFilterPDFToPDF() filter function and others)=====
+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.
-contributor full-size (350 hours).
+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.
-Like CUPS, 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++%%.
+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.
-But libcupsfilters still depends on one library which is written in %%C++%%, 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().
+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.
-Michael Sweet, author of CUPS, has some years ago started the PDFio project. This is a PDF handling and manipultion library, as QPDF is, but it is fully written in standard, regular C, no C++.
+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.
-Therefore we want to replace the use of QPDF by PDFio and this is what this GSoC project is about.
+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.
-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.
+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).
-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.
+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, ...).
-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
+CPDB support for the print dialog of the Chromium Browser is already done by Kushagra Sharma in GSoC [[https://github.com/kushagra20251/GSoC/|2023]].
-Desired knowledge: %%C/C++%%, CUPS
+For the CPDB integration we do not need UI design work.
-Code License: Apache 2.0
+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
+Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
-=====CPDB backend for IPP infrastructure/cloud printers=====
+Code License: MIT, GPL-2+ and LGPL-2+
-=====Turn cups-browsed into a Printer Application=====
+=====Desktop Integration: Update system-config-printer for the New Architecture of printing=====
-=====Printer Application for Braille embossers=====
+contributor full-size (350 hours).
+Originally, we already had discontinued the development of system-config-printer and put it into maintenance mode, only fixing bugs and collecting UI translations.
-=====Adding support for the new functionality/attributes of IPP Everywhere 2.x to libcupsfilters and the Common Print Dialog Backends (CPDB)=====
+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.
--2 contributors full-size (350 hours).
+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.
-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.
+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.
-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.
+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.
-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.
+And this is the contributor's task in this project.
-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.
+Note that system-config-printer is written in Python.
-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), TBD
-Desired knowledge: %%C/C++%%, CUPS
+Desired knowledge: Python, C, CUPS
-Code License: Apache 2.0
+Code License: GPL-2+ (GPL 2 or any later version)
+=====Desktop Integration: User interfaces for using OAuth2 with printers and scanners=====
-=====CPDB support for application's print dialogs: Firefox, Chromium, LibreOffice, ...=====
 contributor full-size (350 hours).
-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.
+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).
-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.
+Authorization in printing is needed to once protect the data of confidential jobs, and second, to protect printer resources, like toner or paper.
-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.
+OAuth2, standard for authorization for internet services ("Log in with Google") is also used as authorization standard for IPP (Internet Printing Protocol) printing.
-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.
+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.
-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.
+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 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.
+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.
-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.
-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).
-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, ...).
-For the CPDB integration we do not need UI design work.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Firefox/Thunderbird/Mozilla developers, Chrome developers, LibreOffice developers, 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++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
-Code License: MIT, GPL-2+ and LGPL-2+
+Code License: Apache 2.0, MIT, GPL-2+ and LGPL-2+
+=====Replace QPDF by PDFio as PDF manipulation library in libcupsfilters (cfFilterPDFToPDF() filter function and others)=====
-=====Scanning support in PAPPL=====
 contributor full-size (350 hours).
-In the Google Summer of Code 2021, Bhavna Kosta has started the work on [[https://github.com/Bhavna2020/GSoC-2021|Scanning support in PAPPL]] (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.
+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++%%.
-She has created the [[https://github.com/michaelrsweet/pappl/tree/scanning|needed data structures and API functions]] needed to extend PAPPL for supporting scanners.
+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().
-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.
+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++%%.
-Next steps to complete the support are the following:
+Therefore we want to replace the use of QPDF by PDFio and this is what this GSoC project is about.
-  * 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, ...
+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.
-  * 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.
+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), Rishabh Maheshwari (rishphalod7 at gmail dot com), Deepak Patankar (patankardeepak04 at gmail dot com)
+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=====
@@ Line 268: / Line 258: @@
 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).
-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.
+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.
-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.
+For long-term support and wide availability, this needs to be converted to the newer CUPS infrastructure, Printer Applications.
-On this page you can create, copy, edit, and delete presets.
+The contributor's task is thus:
-You see a list of the existing presets, each with buttons for copy, edit, and delete. At the top you see the create button.
+  * Converting these shell scripts into filter functions in libcupsfilters
+  * Creating a Printer Application that exposes Braille embossers configuration to users
-If you click on the create button, you will get on the page for editing a preset.
+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.
-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.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Samuel Thibault, Braille expert (samuel dot thibault at ens-lyon dot org)
-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.
+Desired knowledge: %%C/C++%%, Shell, CUPS
-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=====
@@ Line 337: / Line 307: @@
 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).
@@ Line 348: / Line 317: @@
 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 362: / Line 331: @@
 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=====

Wiki

User Tools

Site Tools

Differences

Page Tools