Differences

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

--- gsoc:google-summer-code-2017-openprinting-projects [2017/01/13 17:28]
till [Foomatic: Generating CUPS PPD generator (/usr/share/cups/drv/*.drv files) from Foomatic data]
+++ gsoc:google-summer-code-2017-openprinting-projects [2017/01/27 14:08] (current)
till [Common Print Dialog for desktop applications and mobile devices (up to 3-4 students)]
@@ Line 13: / Line 13: @@
 Code License: See project descriptions
-=====Improve the pdftopvp filter to not need copying Poppler source code or unstable APIs and/or make it Ghostscript/MuPDF-based=====
+=====Common Print Dialog for desktop applications and mobile devices (up to 3-4 students)=====
-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.
+To make printing easy for the users of desktop systems and mobile devices he once needs a well-designed print dialog where he can easily find the right printer under the available printers, set general, printer-specific, and document-specific options, preview the printout, and send the job. But he also neds consistence between applications, printing should work the same way from every application, the print dialog should be the same all over the system.
-One of the filters is pdftoopvp which is the interface between PDF (the standard print job format under Linux) and the OpenPrinting Vector high-level printer driver interface standard. This standard is currently used by several Japanese-market laser printers which do not use PostScript as it is usual in Europe and the US.
+For the dialog itself there is already a design of how the user interface could look like. It was done by the design team of Canonical (the company behind Ubuntu) and can be found [[https://wiki.ubuntu.com/Printing|on the Ubuntu Wiki]]. The dialog should support three ways of obtaining available printers: Most importantly it should list the local CUPS queues and get printer properties and options through CUPS. It also should be able to pick IPP network printers from the network via Bonjour/DNS-SD and query the printer's properties via IPP (mainly for mobile devices to use IPP Everywhere and AirPrint printers). The third way is to connect to the user's Google account to list the Google Cloud Print printers which the user has registered.
-This filter currently only supports Poppler as PDF renderer and the connection between the filter and Poppler is rather awkward, copying parts of Poppler's source code and using unstable APIs of Poppler which change with newer Poppler versions. This makes maintaining the filter difficult for the Linux distributions.
+To allow for the print dialog being provided by the currently running desktop (Unity, GNOME, KDE, ...) or mobile environment while the different applications use different GUI toolkits (GTK, Qt, ...) the print dialog and the application should be implemented in different executables which communicate by D-Bus. An appropriate D-Bus interface got already [[:openprinting:cpdapi|designed earlier]]. Probably the design can already be used as it is, perhaps it needs some slight modifications.
-The task for the student is here to once improve the interface with Poppler if possible and also add support for Ghostscript (would improve color management a lot) and MuPDF (would improve integration with mobile and embedded devices). The tasks can be split up over up to 3 students (Poppler, Ghostscript, MuPDF).
+The task for the student(s) is to implement the dialog with a major toolkit (GTK or Qt) or to add the D-Bus interface to call the Common Print Dialog to a major toolkit or an important application.
-Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Koji Otani, BBR Inc. Japan (sho at bbr dot jp), Ghostscript developers TBD
+At OpenPrinting there has already been worked on a similar project earlier. See the resources  [[:openprinting:commonprintingdialog|here]].
-Desired knowledge: C and/or C++ programming
+This project will be divided under several students (GTK dialog, Qt dialog, D-Bus interfaces for applications/GUI toolkits, ...).
-Code License: MIT
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Aveek Basu (basu dot aveek at gmail dot com), Ubuntu GUI developers TBD
-=====Foomatic: Improving the PPD generation capabilities: Option conflicts and printer compatibility classes=====
-[[:openprinting:database:foomatic|Foomatic]] serves now well for more than 15 years for integrating Ghostscript-based printer drivers with the printing environment under Linux (usually CUPS). Based on an XML database of printers, drivers, and user-settable driver options PPD (Postscript Printer Description) files are generated and used together with the universal print filter foomatic-rip. This way the user has access to all the driver's (and printer's) capabilities and Ghostscript is correctly called by the printing system to execute the print job.
+Desired knowledge: C/C++ programming, GUI programming, GTK, Qt, D-Bus
-This worked principally very well. One can really control all options of the printer drivers and even more sophisticated techniques, like CUPS' custom options (arbitrary numbers and strings as parameters) are supported.
+=====Flattening non-static content (like filled forms) in PDF files for printing (1 student)=====
-But there are still two problems which did not get addressed due to the lack of manpower for implementing them:
+For printing a job usually applications generate PDF files and send them to the printing system ([[http://www.cups.org/|CUPS]]), where a post-processing filter (pdftopdf of [[:openprinting:cups-filters|cups-filters]]) does manipulations like N-up (N pages per sheet), scale page to fit sheet size, printing pages in reverse order, printing only even/odd, pages, selected pages, ... and the resulting PDF file is passed through further filters to turn it into a format which the printer understands.
-//Option setting conflicts//
+This works very well with PDF files especially generated for printing. Generally, PDF files can have so-called synamic content, content which can easily get exchanged after creating the PDF file. Here are especially to mention PDF files containing a form which the user can fill in, like tax forms, registration forms, ... The user sometimes is supposed to send back the form by e-mail, which is no problem, but sometimes he has to print it, sign it, and return it as paper. Especially if it gets sent to the printer from a file manager or from the command line the PDF file with the filled form gets sent to the printing system and if the pdftopdf filter tries to do manipulations on it, the form content gets lost in the printout.
-Often option settings do not work together, like printing double-sided on transparencies. PPD files use the "*UIConstraints: ..." keyword to mark these conflicts so that in print dialogs and printer setup tools one cannot choose conflicting settings.
+To avoid this, the pdftopdf filter needs to recognize that the input has dynamic content and before doing any manipulations this content needs to get flattened, meaning that it needs to get turned into static content, which will be the task of the student taking this project.
-Foomatic has no functionality to define option setting conflicts and generate appropriate "*UIConstraints: ..." keywords in the PPD files.
+pdftopdf uses the [[http://qpdf.sourceforge.net/|QPDF library]] to manipulate PDF files without rendering them. To keep it simple and to improve the capabilities of the QPDF library, the best solution would be to implement this as a new feature of the QPDF library (and make pdftopdf only calling the appropriate function(s)).
-//Printer compatibility classes//
+See also the following bug reports which lead to this project: [[https://bugs.launchpad.net/ubuntu/+source/qpdf/+bug/1564249|in Ubuntu]], [[https://bugs.linuxfoundation.org/show_bug.cgi?id=1315|in cups-filters]]
-The other problem is that it is rather awkward to assign drivers and options to printers if there are very many similar, compatible models. Often one has to mention each printer explicitly in the driver and option XML entries.
+Mentors: Jay Berkenbilt (ejb at ql dot org), Tobias Hoffmann (smilingthax at googlemail dot com)
-Instead of needing to add many compatible printers to the drivers and to the constraints of options one could introduce compatibility classes. A compatibility class contains absolutely compatible printers, which means printers which work with the same drivers, the same options, and the same choices for the options. Then one can put the class name into the list of supported printers of a driver and also into the constraints of the options and so one avoids needing to insert tenth of printers everywhere. Especially there are many HP inkjets which are absolutely compatible to each other (around ten classes instead of 100 printers) and there are many clones of HP LaserJet printers.
+Desired knowledge: C/C++ programming
-What is needed for solving both problems is an extension to XML database, to the SQL representation of the database (for accelerated database access), to the OpenPrinting web site, and to the PPD file generator.
+Code License: MIT, Artistic 2.0
-Mentor: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
+=====Google Cloud Print: Desktop-integrated solution for registering local CUPS printers (1 student)=====
-Desired knowledge: Perl programming, PHP, MySQL
+[[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.
-Code License: GPL
+To do so, one needs a Google account and there one registers one's printers so that they can accept jobs sent into the print facility of this Google account.
-=====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.
+On Linux there is already a way to share the local CUPS printers into Cloud Print: The Chrome/Chromium Browser. In its settings you can activate Google Cloud Print and the local queues get registered. The Browser even leaves a user daemon running when one closes it to continue keeping the printers available for Cloud Print.
-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 disadvantage of this is that the functionality is bound to a web browser, so it is awkward for people who use Firefox for example.
-The latter is not yet supported by Foomatic and letting Foomatic support it is subject of this project idea.
+Do not suggest now to make the CUPS daemon (daemon which handles the print jobs) or cups-browsed (daemon which browses the network for printers and automatically creates local queues for them) registering the printers, as they are system-wide services and Google Cloud Print is based on the user's Google account, and so something which belongs to a single user.
-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.
+What is needed is a user daemon which starts when logging in and stops when logging out, running with the rights of the user, connecting to the user's Google account registering the local CUPS printers the user is allowed to print on. It will need integration with the desktop for starting and stopping the daemon and for configuration in the desktop's settings utility.
-Mentor: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
+Ideally it should work with the widespread Unity desktop but also GNOME support would be great.
-Desired knowledge: Perl programming, perhaps also MySQL
+[[https://developers.google.com/cloud-print/docs/devguide|Google documentation for printer registration]].
-Code License: GPL
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Ubuntu/Unity/GNOME GUI developers TBD
-=====GTK (GNOME) Print Dialog: Support for driver-less printing on network printers, especially also IPP Everywhere printers=====
-cups-browsed is a daemon which comes with the [[:openprinting:cups-filters|cups-filters]] package from OpenPrinting and it discovers remote printers and automatically creates local print queues so that these remote printers are available locally. On desktop Linux distributions it is usually configured to only discover remote CUPS printers as they have a driver on the server side.
+Desired knowledge: C/C++ programming, GUI programming, GTK
-Mainly for printing on mobile devices without needing to set up anything cups-browsed can also discover IPP network printers with known page description languages (PostScript, PDF, PWG Raster, PCL) and set up print queues for them which accept PDF as input and turn data into the language needed by the printer. To have driver-less (no software or data files specific to the printer model) printing, these queues do not have a PPD (PostScript Printer Description) file which tells clients about printer-specific capabilities and user-settable options, meaning that if you print to such queues printing is done with everything on default (A4, one-sided, normal quality, ...) as the print dialogs do not show any changeable options.
+=====Improve the pdftopvp filter to not need copying Poppler source code or unstable APIs and/or make it Ghostscript/MuPDF-based (up to 3 students)=====
-The student's task here is to create a backend for the GTK print dialog (the most used print dialog for desktop applications under Linux) which recognizes such print queues and polls the printer's capability list directly from the printer via IPP as soon as the user selects the printer and then set up the option panel of the dialog based on the found IPP options and choices and when printing send the job along with the user's settings and also static capabilities (like unprintable margins).
+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.
-This way the user can simply print on an available network printer and make use of most of the printer's capabilities without needing to set up a print queue for the printer or have a driver for it.
+One of the filters is pdftoopvp which is the interface between PDF (the standard print job format under Linux) and the OpenPrinting Vector high-level printer driver interface standard. This standard is currently used by several Japanese-market laser printers which do not use PostScript as it is usual in Europe and the US.
-Especially there will soon be printers following the IPP Everywhere standard from the Printing Working Group ([[http://www.pwg.org/|PWG]]). These are IPP 2.x printers which understand at least PWG Raster but often also other languages and they inform clients about all their capabilities. These printers are designed for driver-less printing.
+This filter currently only supports Poppler as PDF renderer and the connection between the filter and Poppler is rather awkward, copying parts of Poppler's source code and using unstable APIs of Poppler which change with newer Poppler versions. This makes maintaining the filter difficult for the Linux distributions.
-Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com).
+The task for the student is here to once improve the interface with Poppler if possible and also add support for Ghostscript (would improve color management a lot) and MuPDF (would improve integration with mobile and embedded devices). The tasks can be split up over up to 3 students (Poppler, Ghostscript, MuPDF).
-Desired knowledge: C programming
+Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Koji Otani, BBR Inc. Japan (sho at bbr dot jp), Ghostscript developers TBD
-Code License: LGPL-2+
+Desired knowledge: C and/or C++ programming
-=====PWG Job-Ticket backend for libJTAPI (Job Ticket API)=====
-Job tickets are extended descriptions for print jobs. They tell which documents should be printed, on which type of paper, which resolution and quality, whether there should be sheets inserted between the documents, ..., and even information like delivery address, payment, ... A job ticket accompanies a print job from its submission to its delivery. Job tickets come from the professional printing world. In former times they were a paper form with instructions what everyone involved in the printing process has to do. Nowadays they are standardized files which are used by print servers, printers, and production printing machines.
+Code License: MIT
+=====Foomatic: Improving the PPD generation capabilities: Option conflicts and printer compatibility classes (1 student)=====
-IPP Everywhere is a next generation printing protocol by the Printing Work Group (PWG) and uses job tickets for all printing metadata. This makes job ticket handling vital for IPP Everywhere support. For IPP Everywhere the PWG has created the [[ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-pjt10-20120801-5108.07.pdf|PWG Job Ticket format]].
+[[:openprinting:database:foomatic|Foomatic]] serves now well for more than 15 years for integrating Ghostscript-based printer drivers with the printing environment under Linux (usually CUPS). Based on an XML database of printers, drivers, and user-settable driver options PPD (Postscript Printer Description) files are generated and used together with the universal print filter foomatic-rip. This way the user has access to all the driver's (and printer's) capabilities and Ghostscript is correctly called by the printing system to execute the print job.
-[[http://bzr.linuxfoundation.org/loggerhead/openprinting/libjtapi/files|Libjtapi]] is OpenPrinting's reference implementation of the FSG's [[https://wiki.linuxfoundation.org/en/OpenPrinting/JTAPI|JTAPI]] standard. The FSG (Free Standards Group) was a predecessor to the Linux Foundation. The JTAPI standard defines an abstract api for producing and consuming job tickets. Thus Libjtapi can create Job Tickets and translate between job ticket formats provided a backend has been developed.
+This worked principally very well. One can really control all options of the printer drivers and even more sophisticated techniques, like CUPS' custom options (arbitrary numbers and strings as parameters) are supported.
-This project is to develop a Libjtapi backend for the PWG's job ticket format. This backend should be able to consume PWG tickets and produce PWG tickets.
+But there are still two problems which did not get addressed due to the lack of manpower for implementing them:
-//**Proposed Tasking:**//
+//Option setting conflicts//
-//**Objective:**// Develop a Libjtapi backend for accepting, parsing, interpreting and translating PWG Job Tickets to LibJTAPI objects/attributes.
+Often option settings do not work together, like printing double-sided on transparencies. PPD files use the "*UIConstraints: ..." keyword to mark these conflicts so that in print dialogs and printer setup tools one cannot choose conflicting settings.
-//**Approach: **//As Libjtapi is written in C89 this backend should be as well. PWG Job Tickets can come in either XML or JSON flavours and only one of these flavours must be supported. A JSON or XML parsing library written in C89 and relicensable under the EPL should be used. The backend may be written using internal Libjtapi helper functions or against the more verbose jtapi apis.
+Foomatic has no functionality to define option setting conflicts and generate appropriate "*UIConstraints: ..." keywords in the PPD files.
-//**Code License:**// [[http://www.eclipse.org/legal/epl-v10.html|EPL]]
+//Printer compatibility classes//
-//**Coding Language:**// [[https://en.wikipedia.org/wiki/C_%28programming_language%29#ANSI_C_and_ISO_C|C89]]
+The other problem is that it is rather awkward to assign drivers and options to printers if there are very many similar, compatible models. Often one has to mention each printer explicitly in the driver and option XML entries.
-//**Coding Document:**// In-line commenting must be sufficient to understand the flow and any section requiring extended understanding.
+Instead of needing to add many compatible printers to the drivers and to the constraints of options one could introduce compatibility classes. A compatibility class contains absolutely compatible printers, which means printers which work with the same drivers, the same options, and the same choices for the options. Then one can put the class name into the list of supported printers of a driver and also into the constraints of the options and so one avoids needing to insert tenth of printers everywhere. Especially there are many HP inkjets which are absolutely compatible to each other (around ten classes instead of 100 printers) and there are many clones of HP LaserJet printers.
-//**Operating System:**// Student’s choice – Linux, Windows, Mac, ... (non-gui for either)
+What is needed for solving both problems is an extension to XML database, to the SQL representation of the database (for accelerated database access), to the OpenPrinting web site, and to the PPD file generator.
-//**Interface:**// Command Line
+Mentor: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com)
-//**Document:**// //Minimum://
+Desired knowledge: Perl programming, PHP, MySQL
-  - How to build the PWG Job Ticket backend.
+Code License: GPL
-  - How to build the test suite
+=====Foomatic: Generating CUPS PPD generator (/usr/share/cups/drv/*.drv files) from Foomatic data (1 student)=====
-  - How to run the test suite
-  - Three example PWG job tickets that can be consumed and produced without data loss.
-Mentor: Glen Petrie, Epson (glen dot petrie at eitc dot epson dot com)
+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.
-Desired knowledge: C Programming
+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.
-=====Get the cairo color management code upstream=====
+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
+=====Get the cairo color management code upstream (1 student)=====
 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 131: / Line 136: @@
 Skills: Understanding of basic color management, basic use of bzr and git, proficient in C.
-Contact: Richard Hughes
+Contact: Richard Hughes (hughsient at gmail dot com)
-=====Add printer output backends to MuPDF=====
+=====Add printer output backends to MuPDF (1-2 students)=====
 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.
@@ Line 146: / Line 151: @@
 This project can be split to be worked on by more than one student.
-Mentors: MuPDF developers TBD, Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
+Mentors: MuPDF developers TBD, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com)
 Desired knowledge: C and/or C++ programming

Wiki

User Tools

Site Tools

Differences

Page Tools