Differences

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

--- gsoc:google-summer-code-2024-openprinting-projects [2024/01/18 19:02]
till [Scanner Applications]
+++ gsoc:google-summer-code-2024-openprinting-projects [2024/01/21 00:40]
till
@@ Line 117: / Line 117: @@
   * [[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 132: / Line 132: @@
 ======Project Ideas======
-=====Adding support for the new functionality/attributes of IPP Everywhere 2.x to libcupsfilters and the Common Print Dialog Backends (CPDB)=====
+=====Desktop integration: CPDB support for the print dialogs of Mozilla (Thunderbird/Firefox) and LibreOffice=====
 -2 contributors full-size (350 hours).
-Driverless IPP printing is implemented with four, very similar standards, IPP Everywhere, AirPrint, Mopria, and Wi-Fi Direct Print. Most [[https://openprinting.github.io/printers/|printers]] qualify to be driverless as the support [[https://support.apple.com/en-us/HT201311|Apple's Airprint]], the standard which got widely used first, to allow printing from iPhones and other iOS devices, but IPP Everywhere from the Printer Working Group is the first free and open standard.
+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.
-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.
-The software provided on OpenPrinting is all based on IPP Everywhere 1.x and to make use of printer features covered by the new version of the standard it needs to get updated.
-The contributor's task is to add the new features according to the new specifications and to update everything to conform with [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve20-20221107.pdf|IPP Everywhere 2.0]], [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippnodriver20-20221027.pdf|IPP Driver Replacement Extensions v2.0]], and [[https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobext21-20221212.pdf|IPP Job Extensions v2.1]]. Especially the libcupsfilters and CPDB must "understand" the new attributes and choices, libcupsfilters needs to implement the new attribute's functionality, and CPDB to carry through the new attributes to the print dialogs.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Ira McDonald (blueroofmusic at gmail dot com), TBD
-Desired knowledge: %%C/C++%%, CUPS
-Code License: Apache 2.0
-=====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.
 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.
@@ Line 171: / Line 152: @@
 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, ...).
+The contributor's task is to get CPDB into the print dialogs upstream, the UI of them does not need to be changed. Dialogs to be treated are Mozilla for Firefox and Thunderbird, and also LibreOffice, and any other application-specific dialog if we have missed it by now. For LibreOffice there was already worked on CPDB support back in 2017, but in the meantime things have changed and the dialog needs to get updated, especially for the new features of CPDB 2.x (human-readable strings/translations, option groups, ...).
+CPDB support for the print dialog of the Chromium Browser is already done by Kushagra Sharma in GSoC [[https://github.com/kushagra20251/GSoC/|2023]].
 For the CPDB integration we do not need UI design work.
-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), Firefox/Thunderbird/Mozilla developers, LibreOffice developers, TBD
 Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
@@ Line 181: / Line 164: @@
 Code License: MIT, GPL-2+ and LGPL-2+
+=====Desktop Integration: Update system-config-printer for the New Architecture of printing=====
+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.
+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.
+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.
+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.
+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.
+And this is the contributor's task in this project.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
+Desired knowledge: Python, C, CUPS
+Code License: GPL-2+ (GPL 2 or any later version)
-=====Scanning support in PAPPL=====
+=====Desktop Integration: User interfaces for using OAuth2 with printers and scanners=====
+=====Replace QPDF by PDFio as PDF manipulation library in libcupsfilters (cfFilterPDFToPDF() filter function and others)=====
 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
+=====CPDB backend for IPP infrastructure/cloud printers=====
@@ Line 232: / Line 238: @@
 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 300: / Line 286: @@
 Code License: Apache 2.0
 =====CI Testing programs for libcupsfilters, libpappl-retrofit, libppd, CPDB, ...=====
@@ Line 327: / Line 312: @@
 Code License: Apache 2.0, MIT
-=====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