Differences

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

--- gsoc:google-summer-code-2019-openprinting-projects [2019/01/14 22:09]
till created
+++ gsoc:google-summer-code-2019-openprinting-projects [2019/01/24 22:30] (current)
till
@@ Line 20: / Line 20: @@
 ======Project Ideas======
-=====2. SANE module for IPP driverless scanning=====
+=====Generic Framework to turn legacy drivers consisting of CUPS filters and PPDs into Printer Applications=====
+Classic printer drivers for CUPS-based printing environment consist of print filters which convert a known page data format (like CUPS/PWG Raster, PostScript, PDF, ...) into the printer's native data format and PPD (PostScript Printer Description) files which describe the printer's capabilities, user-settable options, and the way how the print filters are used.
+The PPD files and print filters have to be put into standardized directories of the installed CUPS system so that CUPS finds them and allows the selection of this printer driver when setting up a printer (or selects the driver automatically when identifying a printer as supported).
+This method works well in standard desktop and server systems using RPM or Debian packages and when the source code of the driver's filters is available or the driver is packaged for the operating system distribution in use. If the CUPS environment is provided in a sandboxed package [[https://github.com/OpenPrinting/printing-stack-snap|like this Snap]] adding files to the CUPS installation is not possible, and in addition, one wants to provide the drivers in distribution-independent binary packages, as for example Snaps. Also the CUPS project is deprecating the use of PPD files.
+The solution, suggested by Michael Sweet, the author of CUPS, are Printer Applications. Printer Applications are simple daemons which emulate a driverless IPP network printer on localhost, do the conversion of the print jobs into the printer's format, and send the job off to the printer. And as a physical driverless IPP printer they advertise themselves via DNS-SD and provide there capability information on (IPP) request from the client.
+The IP connection between CUPS and the Printer Application allows both being in different sandboxes (for example being installed from different Snap packages) and the printer setup is completely automatic. When the Printer Application's daemon is running and the printer is connected and turned on, the daemon discovers the printer and automatically advertises it on the local machine via DNS-SD. Then CUPS discovers the printer and automatically sets up a print queue with an auto-generated PPD file.
+The student's tasks here are
+  * Create a universal printer application framework which can be packaged with print filters and PPDs to make up a Printer Application
+  * Use this framework to create Printer Applications for drivers like HPLIP, foo2zjs, Gutenprint, SpliX, ...
+  * Use this framework to make a Printer Application for Foomatic
+  * Making Snaps of Printer Applications.
+Existing free software which could be used to accomplish this task are [[http://www.cups.org/|CUPS/libcups]], [[https://github.com/istopwg/ippsample|PWG's ippsample]], [[https://github.com/OpenPrinting/cups-filters|cups-filters]], [[http://www.ghostscript.com/|Ghostscript]], [[https://mupdf.com/|MuPDF]], ...
+The tasks can be distributed to more than one student if needed.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
+Desired knowledge: C programming, DNS-SD, IPP
+Code License: Apache 2.0, MIT
+=====IPP scan (or virtual MF device) server (Scanner Application)=====
+The Internet Printing Protocol (IPP) does not only support printing, but also scanning, as there are many printers which also have a scanner (multi-function (MF) devices). Both CUPS and the developer tool ippserver emulate IPP network printers but not IPP scanners and so they cannot serve as a server to share a local scanner.
+This task is about adding the scan server functionality. If you have a scanner connected locally (and it scans via SANE), share it as an IPP scanner, advertising itself and accepting jobs using the IPP driverless scanning standard. In contrary to SANE-based network scanning clients with any operating system, also phones or IoT devices can scan on your shared scanner.
+Also old hardware can be recycled to a modern MF device, and we have a sample implementation to motivate manufacturers to adopt IPP scanning.
+This server software will be a so-called Scanner Application, a sample implementation of the future form of scanner drivers, easily packageable in sandboxed, distribution-independent package formats like Snap.
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), SANE upstream developers TBD
+Desired knowledge: C programming, DNS-SD, IPP
+Code License: Apache 2.0
+=====SANE module for IPP driverless scanning=====
 Version 2.0 and newer of the Internet Printing Protocol (IPP) support polling the full set of capabilities of a printer and if the printer supports a known Page Description Language (PDL), like PWG Raster, Apple Raster, PCLm, or PDF, it is possible to print without printer-model-specific software (driver) or data (PPD file), so-called "driverless" printing. This concept was introduced for printing from smartphones and IoT devices which do not hold a large collection of printer drivers. Driverless printing is already fully supported under Linux. Standards following this scheme are IPP Everwhere, Apple AirPrint, Mopria, and Wi-Fi Direct Print.
@@ Line 26: / Line 70: @@
 Conventional scanners are supported under Linux via the SANE (Scanner Access Now Easy) system and require drivers specific to the different scanner models. Most of them are written based on reverse-engineering due to lack of support by the scanner manufacturers. To get driverless scanning working with the software the users are used to the best solution is to write a SANE module for driverless IPP scanning. This module will then automatically support all IPP scanners, thousands of scanners where many of them do not yet exist.
+Even if there are no driverless IPP scanners on the market yet, this module can be used for accessing scanners with their driver provided as Scanner Application (see previous project in this list).
 The student's task is to write this SANE module for IPP driverless scanning and so make Linux ready for the future of driverless devices.
@@ Line 35: / Line 81: @@
 Code license: GPL 2+
-=====3. IPP scan (or virtual MF device) server=====
+=====IPP: ipptool test suite for IPP System Service=====
-The Internet Printing Protocol (IPP) does not only support printing, but also scanning, as there are many printers which also have a scanner (multi-function (MF) devices). Both CUPS and the developer tool ippserver emulate IPP network printers but not IPP scanners and so they cannot serve as a server to share a local scanner.
+ipptool is a command line tool for issuing IPP requests and receiving printer's/server's responses.  ipptool is maintained as free software in the ippsample collection from the IEEE-ISTO Printer Working Group (PWG). ipptool is used for development and debugging of IPP-related software and for PWG self-certification for IPP Everywhere printers for driverless printing.
-This task is about adding the scan server functionality. If you have a scanner connected locally (and it scans via SANE), share it via CUPS as an IPP scanner, advertising itself and accepting jobs using the IPP driverless scanning standard. In contrary to SANE-based network scanning clients with any operating system, also phones or IoT devices can scan on your shared scanner.
+The student's task is to develop additional ipptool test scripts for all new operations, objects, attributes defined in IPP System Service v1.0 (e.g., Create-Printer).
-Also old hardware can be recycled to a modern MF device, and we have a sample implementation to motivate manufacturers to adopt IPP scanning.
+Mentors: Ira McDonald (blueroofmusic at gmail dot com), Printing Working Group, Smith Kennedy (smith dot kennedy at hp dot com), HP, TBD
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
+Desired knowledge: C programming, IPP
-Desired knowledge: C programming, DNS-SD, IPP
+Code License: Apache 2.0
+=====IPP: ipptool test suite updates for IPP errata updates=====
+ipptool is a command line tool for issuing IPP requests and receiving printer's/server's responses.  ipptool is maintained as free software in the ippsample collection from the IEEE-ISTO Printer Working Group (PWG). ipptool is used for development and debugging of IPP-related software and for PWG self-certification for IPP Everywhere printers for driverless printing.
+The student's task is to develop additional ipptool test scripts for IPP errata including IPP Document Object v1.1, IPP Job Extensions v1.1, and IPP 3D Printing Extensions v1.1.
+Mentors: Ira McDonald (blueroofmusic at gmail dot com), Printing Working Group, Smith Kennedy (smith dot kennedy at hp dot com), HP, TBD
+Desired knowledge: C programming, IPP
 Code License: Apache 2.0
-=====4. Support for IPP System Service=====
+=====Linux GUI application (can be part of GNOME printer tool) to admin MF devices using IPP System Service.=====
 Most network printers have a web interface which allows to configure the printer from any computer in the network using a web browser. Advantage is that no printer-model-specific software needs to be installed on the computer in order to configure a printer, and one has no dependency on certain supported operating systems. One can even configure printers using a smartphone.
@@ Line 64: / Line 119: @@
 Code License: GPL 2+ or LGPL 2+
-=====5. Secure (IPPS/HTTPS) connection support for IPP-over-USB=====
+=====Improve the pdftoraster filter to not need copying Poppler source code or using unstable APIs=====
-Driverless printing was originally designed for network printers, a client device, typically a smartphone, tablet, or IoT device) discovers printers nearby via DNS-SD and then communicates with them via Internet Printing Protocol (IPP), which is based on the HTTP web protocol. Printers even use HTTP in addition to IPP, for their administration web interfaces. For more security many printers support also the encrypted versions of these protocols, HTTPS and IPPS.
+The cups-filters project at OpenPrinting (included in all Linux distributions using CUPS 1.6.x or newer) provides the filters needed to convert the print job output of desktop applications (usually PDF) into the printer's native language or into the universal CUPS/PWG-Raster format as input for a separate printer driver. It also provides the pdftopdf filter to apply page management (N pages per sheet, selected pages, even/odd pages for manual duplex, mirror for iron-on sheets, ...) to the PDF data stream.
-Not only network but also USB printers support driverless printing. A former standard USB protocols for printers allowed only raw job data to be submitted to the printer, IPP-over-USB got introduced, a new USB standard protocol for printers where data is transmitted as packets (like on the network) and the printer understands IPP also through this channel.
+One of the filters, pdftoraster, to rasterize PDF files into CUPS/PWG Raster, uses Poppler but makes use of unstable APIs of Poppler, requiring frequent modifications when Poppler gets updated.
-To make these printers working with CUPS with a minimum of needed code and without duplication large parts of the CUPS code, but also to fulfill the IPP-over-USB standard, we have a daemon which emulates an IPP network printer on localhost, but on a port not already used by CUPS (e. g. 60000). The daemon registers the printer also on Avahi, so that it gets advertised on the local machine and network-printer-supporting system infrastructure as cups-browsed and CUPS create a print queue fully automatically.
+The task for the student is here to improve pdftoraster's interface with Poppler, for example using Poppler's PPM (generic raster) output and converting it into CUPS/PWG Raster. Discussion about possible approaches you can find [[https://github.com/OpenPrinting/cups-filters/issues/9|on the cups-filters GitHub]].
-This daemon is [ippuasbxd](https://github.com/OpenPrinting/ippusbxd) from [OpenPrinting](https://github.com/OpenPrinting/ippusbxd). It works as it should do, conforming to the IPP-over-USB standard, with one exception: There is no encrypted communication support (IPPS/HTTPS).
+Mentors: Sahil Arora (sahilarora dot 535 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Tobias Hoffmann, cups-filters developer (smilingthax at googlemail dot com).
-The task of the student here is to add encrypted communication support to ippusbxd, for both IPPS and HTTPS.
+Desired knowledge: C and/or %%C++%% programming
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
+Code License: MIT
-Desired knowledge: C programming, CUPS, HTTP(S), encryption
+=====Foomatic: Generating CUPS PPD generator (/usr/share/cups/drv/*.drv files) from Foomatic data=====
-Code license: Apache 2.0
+CUPS has two mechanisms for on-the-fly-PPD generation to avoid the wasting of disk space by thousands of uncompressed (or slightly compressed) PPD files. One is to put an executable file into the /usr/lib/cups/driver/ directory which lists and generates PPD files on request, the other is using *.drv files in /usr/share/cups/drv, which contain the data for the PPDs in a simpler and more compact format.
+The former method is deprecated upstream and can be removed in a future release of CUPS, especially also because the executables can get slow in some cases.
-=====6. Printing of files directly from the file manager=====
+The latter is not yet supported by Foomatic and letting Foomatic support it is subject of this project idea.
-Sometimes you browse through your files and see some files which you want to print, files in completely different formats: PDFs, photos, LibreOffice files, ... It is awkward to double-click each file, one-by-one, to get it opened in its application, and then click "Print" in each application. It would be much easier to mark all these files, right-click and then click "Print" in the context menu.
+The student's task is to create a utility which generates *.drv files from the whole database and/or from selected, printers, manufacturers, drivers, groups, ..., depending on what the user requests.
-Here the student's task is to add this functionality to a popular file manager, for example the one of GNOME.
+Mentor: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com)
-Mentors: Aveek Basu (basu dot aveek at gmail dot com), upstream developers of GNOME/GTK TBD.
+Desired knowledge: Perl programming, perhaps also MySQL
-Desired knowledge: C programming, GTK
+Code License: GPL
-Code License: LGPL 2+
+=====Add printer output backends to MuPDF=====
+MuPDF is a lightweight PDF renderer made by Artifex, the company behind Ghostscript. In contrary to Ghostscript, MuPDF is a pure PDF renderer. It does not contain a PostScript interpreter nor parts of it are written in PostScript. This makes it smaller, faster, and less resource-consuming, the ideal solution for mobile devices like tablets or smartphones.
+On mobile devices printing will not be done with having tons of printer-model-specific drivers on the system. Once, they consume the limited mass storage space, and second, one uses the mobile device in several different local networks with different printers: At home, in the office, in a copy shop, ... and one wants to use the printers which are available there, without installing drivers and setting up queues.
+Therefore we want to have a system which automatically detects network printers and makes them available for local apps. To do so we restrict ourselves to printers with known, common languages: IPP Everywhere/AirPrint/Mopria/W-Fi Direct (driverless printing standards, using PWG Raster, Apple Raster, PCLm, and PDF) and PostScript, PDF, PCL 5c/e/6/XL (legacy standards). So MuPDF has to generate raster output for these languages, meaning raster embedded in the specifics of the language, and to avoid exhausting printer resources raster in small bands and no high-level output, even if the printer language is high-level.
+Artifex will also work on this, but to get additional man power we are also opening this project for students.
+Note that you have to assign copyright on your code to Artifex, as otherwise the code cannot be integrated in MuPDF.
+This project can be split to be worked on by more than one student.
+Mentors: MuPDF developers TBD, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com)
+Desired knowledge: C and/or %%C++%% programming
+Code License: GPL
-=====11. Common Print Dialog Qt implementation (1 student)=====
+=====Common Print Dialog Qt implementation=====
 The [[https://doc.qt.io/qt-5.10/qtprintsupport-index.html | Qt Print Support]] framework should be updated with the CPD support. The goal is to provide the CPD GUI features and d-bus communications with the [[https://github.com/OpenPrinting/cpdb-libs | CPD backend support]] for printing from Qt5 applications on support platforms.
@@ Line 102: / Line 176: @@
 Mentors: Dongxu Li (dongxuli2011 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
-Desired knowledge: C++ programming, Qt, CUPS
+Desired knowledge: %%C++%% programming, Qt, CUPS
 Licenses: Qt Contribution Agreement
-=====12. Turn the scp-dbus-service of system-config-printer into C=====
+=====Turn the scp-dbus-service of system-config-printer into C=====
 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 118: / Line 192: @@
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), system-config-printer upstream developers TBD
-Desired knowledge: C/C++ programming, Python programming
+Desired knowledge: C/%%C++%% programming, Python programming
 Code license: GPL 2+ or MIT
-=====13. Google Cloud Print: Desktop-integrated solution for registering local CUPS printers=====
+=====Google Cloud Print: Desktop-integrated solution for registering local CUPS printers=====
 [[https://developers.google.com/cloud-print/docs/overview|Google Cloud Print]] is a service from Google which allows to print from anywhere with internet access to anywhere else with internet access, for example from a mobile phone to printer at home or in the office.
@@ Line 142: / Line 216: @@
 Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Ubuntu/GNOME GUI developers TBD
-Desired knowledge: C/C++ programming, GUI programming, GTK
+Desired knowledge: C/%%C++%% programming, GUI programming, GTK
-=====14. Improve the pdftoraster filter to not need copying Poppler source code or unstable APIs=====
+=====Printing of files directly from the file manager=====
-The cups-filters project at OpenPrinting (included in all Linux distributions using CUPS 1.6.x or newer) provides the filters needed to convert the print job output of desktop applications (usually PDF) into the printer's native language or into the universal CUPS/PWG-Raster format as input for a separate printer driver. It also provides the pdftopdf filter to apply page management (N pages per sheet, selected pages, even/odd pages for manual duplex, mirror for iron-on sheets, ...) to the PDF data stream.
+Sometimes you browse through your files and see some files which you want to print, files in completely different formats: PDFs, photos, LibreOffice files, ... It is awkward to double-click each file, one-by-one, to get it opened in its application, and then click "Print" in each application. It would be much easier to mark all these files, right-click and then click "Print" in the context menu.
-Two of the filters, pdftoraster, to rasterize PDF files into CUPS/PWG Raster, and bannertopdf, to generate banner pages and test pages, use Poppler but make use of unstable APIs of Poppler, requiring frequent modifications when Poppler gets updated. bannertopdf does even not require a PDF interpreter, so it could be implemented with libraries like QPDF.
+Here the student's task is to add this functionality to a popular file manager, for example the one of GNOME.
-The task for the student is here to once improve pdftoraster's interface with Poppler and second to convert bannertopdf to use QPDF.
+Mentors: Aveek Basu (basu dot aveek at gmail dot com), upstream developers of GNOME/GTK TBD.
-Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com),
+Desired knowledge: C programming, GTK
-Desired knowledge: C and/or C++ programming
+Code License: LGPL 2+
-Code License: MIT
+=====Get the cairo color management code upstream=====
-=====15. Foomatic: Generating CUPS PPD generator (/usr/share/cups/drv/*.drv files) from Foomatic data=====
-CUPS has two mechanisms for on-the-fly-PPD generation to avoid the wasting of disk space by thousands of uncompressed (or slightly compressed) PPD files. One is to put an executable file into the /usr/lib/cups/driver/ directory which lists and generates PPD files on request, the other is using *.drv files in /usr/share/cups/drv, which contain the data for the PPDs in a simpler and more compact format.
-The former method is deprecated upstream and can be removed in a future release of CUPS, especially also because the executables can get slow in some cases.
-The latter is not yet supported by Foomatic and letting Foomatic support it is subject of this project idea.
-The student's task is to create a utility which generates *.drv files from the whole database and/or from selected, printers, manufacturers, drivers, groups, ..., depending on what the user requests.
-Mentor: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com)
-Desired knowledge: Perl programming, perhaps also MySQL
-Code License: GPL
-=====16. Get the cairo color management code upstream=====
 Adrian Johnson did a lot of the work needed to make cairo color managed. Finishing this work and getting the code upstream would allow us to simplify a lot of applications that use cairo. See [[http://cgit.freedesktop.org/%7Eajohnson/cairo/log/?h=color-space|http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space]] for the branch. Adrian has also patched Inkscape to use the new features, and that needs cleaning up and pushing upstream [[http://cgit.freedesktop.org/%7Eajohnson/inkscape/log/?h=color-space|http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space]] Also see [[http://lists.cairographics.org/archives/cairo/2012-July/023353.html|http://lists.cairographics.org/archives/cairo/2012-July/023353.html]] and [[https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html|https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html]] for more details.
@@ Line 181: / Line 239: @@
 Contact: Richard Hughes (hughsient at gmail dot com)
-=====17. Add printer output backends to MuPDF=====
-MuPDF is a lightweight PDF renderer made by Artifex, the company behind Ghostscript. In contrary to Ghostscript, MuPDF is a pure PDF renderer. It does not contain a PostScript interpreter nor parts of it are written in PostScript. This makes it smaller, faster, and less resource-consuming, the ideal solution for mobile devices like tablets or smartphones.
-On mobile devices printing will not be done with having tons of printer-model-specific drivers on the system. Once, they consume the limited mass storage space, and second, one uses the mobile device in several different local networks with different printers: At home, in the office, in a copy shop, ... and one wants to use the printers which are available there, without installing drivers and setting up queues.
-Therefore we want to have a system which automatically detects network printers and makes them available for local apps. To do so we restrict ourselves to printers with known, common languages: IPP Everywhere (Upcoming standard, PWG Raster and optionally some others) and PostScript, PDF, PCL 5c/e/6/XL (legacy standards). So MuPDF has to generate raster output for these languages, meaning raster embedded in the specifics of the language, and to avoid exhausting printer resources raster in small bands and no high-level output, even if the printer language is high-level.
-Artifex will also work on this, but to get additional man power we are also opening this project for students.
-Note that you have to assign copyright on your code to Artifex, as otherwise the code cannot be integrated in MuPDF.
-This project can be split to be worked on by more than one student.
-Mentors: MuPDF developers TBD, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com)
-Desired knowledge: C and/or C++ programming
-Code License: GPL

Wiki

User Tools

Site Tools

Differences

Page Tools