Differences

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

--- gsoc:google-summer-code-2022-openprinting-projects [2022/01/26 19:48]
till
+++ gsoc:google-summer-code-2022-openprinting-projects [2022/02/28 17:42]
Aveekb
@@ Line 8: / Line 8: @@
 Mailing list: [[http://lists.linux-foundation.org/mailman/listinfo/printing-architecture|printing-architecture at lists dot linux-foundation dot org]]
-IRC: #openprinting on Freenode
+IRC: #openprinting on [[https://libera.chat/|Libera.Chat]]
-[[https://github.com/OpenPrinting|OpenPrinting GitHub]]
+Our code repositories: [[https://github.com/OpenPrinting|OpenPrinting GitHub]]
 Keep in touch with [[https://openprinting.github.io/news/|OpenPrinting's state of the art]].
@@ Line 55: / Line 55: @@
 Having multi-function printers in mind (printer, scanner, also often fax in one device) the [[https://ftp.pwg.org/pub/pwg/candidates/cs-ippscan10-20140918-5100.17.pdf|IPP Scan]] standard got created, which allows the use of IPP for both printing and scanning. Especially driverless scanning is possible using the same principles as with driverless printing. Manufacturers actually use eSCL and WSD for driverless scanning instead (also [[https://github.com/alexpevzner/sane-airscan|supported in free software]]), but IPP Scan also helps to get scanning working in environments of only sandboxed packages and to more easily distribute scanner drivers.
-Currently, [[http://www.sane-project.org/|SANE]] is the standard platform for scanning. Here a frontend, for example a GUI user appication, like simple-scan or X-SANE, looks for backends (scanner drivers) which are supplied as dynamically loadable shared libraries in a given directory, runs each backend so that it returns back which of its supported scanners are currently present, having the frontend end up with a list of all currently available scanners and through which backend they are available.
+Currently, [[http://www.sane-project.org/|SANE]] is the standard platform for scanning. Here a frontend, for example a GUI user application, like simple-scan or X-SANE, looks for backends (scanner drivers) which are supplied as dynamically loadable shared libraries in a given directory, runs each backend so that it returns back which of its supported scanners are currently present, having the frontend end up with a list of all currently available scanners and through which backend they are available.
-This architecture is not viable for sandboxed packaging, where the user applications are in separate sandboxed packages and one wants to be able to add scanner drivers, preferrably each scanner driver also in a sandboxed package.
+This architecture is not viable for sandboxed packaging, where the user applications are in separate sandboxed packages and one wants to be able to add scanner drivers, preferably each scanner driver also in a sandboxed package.
 So as we create Printer Applications we create Scanner Applications emulating a driverless IPP scanner using the IPP Scan standard. Now scanner drivers can be distributed in individual sandboxed packages, OS-distribution-independent, and for multi-function devices one can even distribute a combined Printer/Scanner Application. The sandboxed packages of user applications which scan only need a backend for IPP Scan and this discovers all Scanner Applications (and scanners in native network devices).
@@ Line 90: / Line 90: @@
 ======Project Ideas======
-**Still needs to get updated!!**
 =====GUI for discovering non-driverless printers and finding suitable Printer Applications for them=====
+contributor full-size (350 hours).
 Modern printers usually are driverless IPP printers, and those get discovered and set up fully automatically with CUPS, no Printer Application is required for them, so it is easy for users to get up and running with them.
@@ Line 109: / Line 109: @@
 Code License: GPL-2+ and LGPL-2+
-=====Converting SANE scanner drivers to Scanner Applications=====
+=====Scanning support in PAPPL=====
-By the time when coding starts we will have implemented IPP Scan server functionality to PAPPL and with this we have the base for creating Scanner Applications. To support the thousands of scanners which are already working with [[http://www.sane-project.org/|SANE]] with the new IPP Scan/Scanner Application method, we need to create a retro-fit Scanner Application which uses SANE internally.
+contributor full-size (350 hours).
-One could theoretically make use of the fact that most SANE backends are open-source and so extract the knowledge about how the scanners work and write native drivers, but without having all these scanners at hand for testing the risk is too high, as mentioned above here for the retro-fitting of printer drivers.
+In the Google Summer of Code 2021, Bhavna Kosta has started the work on [[https://github.com/Bhavna2020/GSoC-2021|Scanning support in PAPPL]] so that [[https://github.com/michaelrsweet/pappl/|PAPPL]] not only can be used for creating Printer Applications (emulation of a driverless IPP printer) but also for creating Scanner Applications (emulation of a driverless IPP/eSCL scanner), or even an emulation of a driverless IPP multi-function device.
-Therefore we want to create a framework to encapsulate existing SANE backends in a Scanner Application and do not modify the code of the backends themselves. This would be a SANE fromtend, but not as the ones we know which are primarily operated by a GUI or by the command line. Instead, it will be operated by IPP Scan and an administration web interface, all with the help of PAPPL.
+She has created the [[https://github.com/michaelrsweet/pappl/tree/scanning|needed data structures and API functions]] needed to extend PAPPL for supporting scanners.
-The student's task is to create this SANE retro-fit framework, especially making one Scanner Application from the sane-backends projects, but also allow to retro-fit any other SANE backend from a separate project (like HPLIP) into a Scanner Application.
+Next steps to complete the support are the following:
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Jai Luthra (luthrajaiji at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), Alexander Pevzner (pzz at apevzner dot com), TBD
+  * IPP Scan interface: Extend the IPP server of PAPPL to understand IPP Scan requests and respond to them appropriately, so that the application emulates an IPP Scan device
+  * eSCL Scan interface: Add an eSCL interface to make the application emulate an eSCL scanner. eSCL is the most common communication protocol for driverless scanning, also used by AirPrint ([[https://github.com/SimulPiscator/AirSane|Code example]])
+  * Create a test scanner driver emulating a scanner withour needing actual scanner hardware
+  * Unit tests for both IPP Scan and eSCL interfaces
-Desired knowledge: %%C/C++%%, CUPS
+The contributor's task to implement the above-mentioned components to complete the framework needed by all Scanner Application. With this done, only code for the particular group of scanners to support (scanner driver) needs to be added to PAPPL.
-Code License: Apache 2.0
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Jai Luthra (luthrajaiji at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), Alexander Pevzner (pzz at apevzner dot com), TBD
-=====cups-filters: Move rastertopwg from CUPS into a filter function=====
-To print on driverless IPP printers following the AirPrint and/or IPP Everywhere standard CUPS got the rastertopwg filter which converts CUPS Raster into PWG Raster and Apple Raster.
-With the move from filters as individual executables to filters as library functions we also want to convert this filter into a filter function in libcupsfilters, allowing the use in Printer Applications and especially also for replacing the CUPS filter chain by a single, universal filter.
-The student's task is to take the code of the rastertopwg filter in CUPS into libcupsfilters, and convert it into a filter function, a function with standardized interfaces for input, output, logging, printer capabilities, job attributes, ...
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD
 Desired knowledge: %%C/C++%%, CUPS
@@ Line 140: / Line 132: @@
 Code License: Apache 2.0
+=====Print Dialogs: Make them use the Common Print Dialog Backends (CPDB)=====
-=====cups-filters: Create a single, universal CUPS filter to replace the chain of individual filters=====
+contributors full-size (350 hours).
-To convert the job data format from the input data type to what the printer needs CUPS calls a sequence of different individual filters, usually one filter to convert the incoming format into PDF (if needed), then the pdftopdf filter to flatten filled PDF forms and to apply page management options (N-up, selected pages, scaling, ...), and after that one or more filters to get the data into the printer's native PDL.
+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 Chrome.
-This makes CUPS call a lot of external executables, which is resource-consuming. Therefore in this project we want to create a universal CUPS filter which causes filter functions in the libcupsfilters library in an appropriate order to replace the work of the current, individual CUPS filters.
+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.
-It should check what the inout format and what the needed output format is and by this select the input filter to get PDF and the output filters to turn PDF into the desired output format, and then it should call the sequence of filter functions.
+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.
-In addition, small improvements on the filter function mechanism could be made, too.
+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 22 years, but within CUPS we have also changes, and they need to be taken care of in the print dialogs.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD
+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.
-Desired knowledge: %%C/C++%%, CUPS
+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.
-Code License: Apache 2.0
+As far as I know the GTK, Qt, and LibreOffice print dialogs support temporary print queues now (but only recently, there are many old dialog versions around), but now we are at the next challenge as we have to assure that the print dialogs use CUPS APIs which do not handle PPDs on the dialog side, so that if the system switched to PPD-less CUPS 3.x that the dialog continues to work. If we get the dialogs using CPDB, these changes happen (if actually needed) only in the CUPS CPDB backend, not in each print dialog individually.
+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 GTK, Qt, (LibreOffice has already CPDB support AFAIR), Chrome, and perhaps others. Also important are backports, as there are many apps based on old toolkit versions around in the distributions (Firefox? Thunderbird?).
-=====cups-filters: Convert filters to filter functions (multiple students)=====
+For the CPDB integration we do not need UI design work.
-cups-filters has always provided the filters which CUPS needs to convert job data from the input format (PDF in most cases) into the printer's native language. For use in Printer Applications the filters got converted from standalone executables to library functions, reducing the number of calls of separate executables and so saving resources. Also for Scanner Applications filters are needd, so that the user can choose the file format he wants.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GNOME/GTK developers, Qt developers, TBD
-Most filtes are already converted, but some are still missing. These are especially:
+Desired knowledge: %%C/C++%%, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
-  * pdftoraster, mupdftoraster: Turn PDF into CUPS/PWG Raster with alternative tools/libraries
+Code License: GPL-2+ and LGPL-2+, Apache 2.0
-  * texttopdf: Input filter for plain text files
-  * bannertopdf: Filter to generate banner pages and a printer test page
-This task can be devided up for more than one student.
+=====Converting Braille embosser support into a Printer Application=====
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD
+contributor full-size (350 hours).
-Desired knowledge: %%C/C++%%, CUPS
+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.
-Code License: Apache 2.0
+For long-term support and wide availability, this needs to be converted to the newer CUPS infrastructure, Printer Applications.
+The contributor's task is thus:
-=====cups-filters: Make sure all filter functions work without PPD files=====
+  * Converting these shell scripts into filter functions in libcupsfilters
+  * Creating a Printer Application that exposes Braille embossers configuration to users
-As already described in the introduction we want to get rid of PPD files in the printing process and control jobs by IPP attributes.
+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.
-For this all filter functions also need to work correctly if there is no PPD file assigned to the print queue. They should as well understand standard IPP attributes as their options and printer IPP attributes for default settings.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Samuel Thibault, Braille expert (samuel dot thibault at ens-lyon dot org)
-The filter function concept already provides the needed interfaces, but the code of each filter function needs to be checked to see whether the filter actually correctly works without a PPD file.
+Desired knowledge: %%C/C++%%, Shell, CUPS
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD
-Desired knowledge: %%C/C++%%, CUPS
 Code License: Apache 2.0
@@ Line 193: / Line 183: @@
 =====cups-filters: In filter functions call Ghostscript via libgs and not as external executable=====
+contributor half-size (175 hrs)
 cups-filters has always provided the filters which CUPS needs to convert job data from the input format (PDF in most cases) into the printer's native language. For use in Printer Applications the filters got converted from standalone executables to library functions, reducing the number of calls of separate executables and so saving resources.
@@ Line 198: / Line 190: @@
 The filter functions themselves also often call external executables, and this we can also try to avoid. For example the ghostscript() filter function calls Ghostscript and Ghostscript also has a library, libgs, which allows Ghostscript to be called as library function.
-The student's task here is to convert the ghostscript() filter function to call Ghostscript via libgs. Here it is also important to make everything working in a multi-threading environment as Printer Applications can process jobs in parallel. Ghostscript has a special GS_THREADSAFE build mode for that.
+The contributor's task here is to convert the ghostscript() filter function to call Ghostscript via libgs. Here it is also important to make everything working in a multi-threading environment as Printer Applications can process jobs in parallel. Ghostscript has a special GS_THREADSAFE build mode for that.
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD
@@ Line 208: / Line 200: @@
 =====cups-filters: Add Avahi calls for discovering and resolving driverless IPP printers to API and optimize the processes=====
+contributor half-size (175 hrs)
 The cups-browsed daemon and the "driverless" utility discover DNS-SD-advertised IPP printers in the network, for the former to automatically create queues and the latter to list the printers for printer setup tools and auto-generate PPD files for them.
@@ Line 217: / Line 211: @@
 The "driverless" utility calls "ippfind" to do the DNS-SD discovery and resolving, here further optimization would be possible if the utility directly deals with Avahi and then saves unneeded resolving steps.
-The student's task is here to add a convenience API for Avahi discovery and resolving calls to libcupsfilters. For example create library functions avahiResolveService(), avahiBrowseResolve(), avahiBrowseOnly() in new files cupsfilters/avahi.[ch], using code of cups/http-support.c and tools/ippfind.c from CUPS. In a next step these functions should be used in cups-browsed and in the "driverless" utility to optimize their performance.
+The contributor's task is here to add a convenience API for Avahi discovery and resolving calls to libcupsfilters. For example create library functions avahiResolveService(), avahiBrowseResolve(), avahiBrowseOnly() in new files cupsfilters/avahi.[ch], using code of cups/http-support.c and tools/ippfind.c from CUPS. In a next step these functions should be used in cups-browsed and in the "driverless" utility to optimize their performance.
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), TBD
@@ Line 227: / Line 221: @@
 =====cups-filters: Create OCR filter to deliver scans as searchable PDFs=====
+contributor half-size (175 hrs)
 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.
@@ Line 234: / Line 230: @@
 Ghostscript has a new "pdfocr8" device with which Ghostscript takes raster graphics PDFs (or PostScript files) as input, applies OCR (Optical Character Recognition) to the raster image, and creates a PDF which contains the raster image to visually show the scan but adds data about the contained text and where it is located, so that you can find text with the search facility of a PDF viewer.
-Here the student's task is to write a filter function (or extend the ghostscript() filter function) to make the "pdfocr8" output device of Ghostscript being used so that a searchable PDF is obtained.
+Here the contributor's task is to write a filter function (or extend the ghostscript() filter function) to make the "pdfocr8" output device of Ghostscript being used so that a searchable PDF is obtained.
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), Alexander Pevzner (pzz at apevzner dot com), TBD
@@ Line 244: / Line 240: @@
 =====Turn the scp-dbus-service methods - GetBestDrivers and MissingExecutables - of system-config-printer into C=====
+contributor full-size (350 hrs)
 system-config-printer was the default printer setup tool in Red Hat/Fedora Linux for a lot of time and also got adopted by Ubuntu around ten years ago. During this time it received a lot of development work, especially on the algorithms for finding the best driver for a printer and for identifying whether printer discovery results from the CUPS backends actually come from the same physical printer.
@@ Line 253: / Line 251: @@
 system-config-printer was written in Python and therefore scp-dbus-service is also written in Python. This makes it depending on Python and also makes it loading the needed Python libraries into memory when started. Also most printer setup tools are written in C, Therefore it makes sense to convert the D-Bus service into the C language.
-The student's task is to turn the two mentioned methods of system-config-printer into C, first as a C library with API, then as a D-Bus service (would
+The contributor's task is to turn the two mentioned methods of system-config-printer into C, first as a C library with API, then as a D-Bus service (would work out-of-the-box with many GUIs) if the C library will be finished. This will make it easier to use those methods in other print tools in practically any programming language.
- work out-of-the-box with many GUIs) if the C library will be finished. This will make it easier to use those methods in other print tools in practically any programming language.
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), system-config-printer upstream developer Zdenek Dohnal (zdohnal at redhat dot com)

Wiki

User Tools

Site Tools

Differences

Page Tools