gsoc:google-summer-code-2022-openprinting-projects
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
gsoc:google-summer-code-2022-openprinting-projects [2022/02/21 22:09] till |
gsoc:google-summer-code-2022-openprinting-projects [2022/03/05 22:51] (current) till |
||
|---|---|---|---|
| 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. | 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). | 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 93: | Line 93: | ||
| =====GUI for discovering non-driverless printers and finding suitable Printer Applications for them===== | =====GUI for discovering non-driverless printers and finding suitable Printer Applications for them===== | ||
| - | 1 contributor full-size | + | 1 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. | 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 111: | Line 111: | ||
| =====Scanning support in PAPPL===== | =====Scanning support in PAPPL===== | ||
| - | 1 contributor full-size OR 2-3 contributors half-size | + | 1 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]] 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. | 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. | ||
| Line 134: | Line 134: | ||
| =====Print Dialogs: Make them use the Common Print Dialog Backends (CPDB)===== | =====Print Dialogs: Make them use the Common Print Dialog Backends (CPDB)===== | ||
| - | 1-2 contributors full-size or 2-3 contributors's half-size | + | 1 contributors 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 Chrome. | 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. | ||
| Line 159: | Line 159: | ||
| Code License: GPL-2+ and LGPL-2+, Apache 2.0 | Code License: GPL-2+ and LGPL-2+, Apache 2.0 | ||
| + | |||
| + | =====Make a native Printer Application from Gutenprint===== | ||
| + | |||
| + | 1 contributor full-size (350 hours). | ||
| + | |||
| + | [[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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | The contributor's task is thus: | ||
| + | |||
| + | * Create a PAPPL-based Printer Application using the libgutenprint library and PAPPL | ||
| + | * 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 | ||
| + | |||
| + | Desired knowledge: %%C%%, PAPPL, CUPS | ||
| + | |||
| + | Code License: Apache 2.0 | ||
| =====Converting Braille embosser support into a Printer Application===== | =====Converting Braille embosser support into a Printer Application===== | ||
| - | 1 contributor full-size | + | 1 contributor full-size (350 hours). |
| cups-filters currently supports Braille embossers through a series of PPD files and shell scripts that convert documents into a textual layout, convert the text into Braille dots, and convert the Braille dots to braille embosser-specific formats. | 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. | ||
| Line 184: | Line 212: | ||
| =====cups-filters: In filter functions call Ghostscript via libgs and not as external executable===== | =====cups-filters: In filter functions call Ghostscript via libgs and not as external executable===== | ||
| - | 1 contributor half-size | + | 1 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. | 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 201: | Line 229: | ||
| =====cups-filters: Add Avahi calls for discovering and resolving driverless IPP printers to API and optimize the processes===== | =====cups-filters: Add Avahi calls for discovering and resolving driverless IPP printers to API and optimize the processes===== | ||
| - | 1 contributor half-size | + | 1 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. | 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 222: | Line 250: | ||
| =====cups-filters: Create OCR filter to deliver scans as searchable PDFs===== | =====cups-filters: Create OCR filter to deliver scans as searchable PDFs===== | ||
| - | 1 contributor half-size | + | 1 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. | 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 241: | Line 269: | ||
| =====Turn the scp-dbus-service methods - GetBestDrivers and MissingExecutables - of system-config-printer into C===== | =====Turn the scp-dbus-service methods - GetBestDrivers and MissingExecutables - of system-config-printer into C===== | ||
| - | 1 contributor full-size | + | 1 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. | 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. | ||
gsoc/google-summer-code-2022-openprinting-projects.1645481362.txt.gz · Last modified: 2022/02/21 22:09 by till
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
