Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ...

Important: We protect the e-mail addresses of our mentors and mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp.

Mailing list: printing-architecture at lists dot linux-foundation dot org

IRC: #openprinting on Freenode

OpenPrinting GitHub

Code License: See project descriptions

The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com).

Please see the plans for our near future work to get an overview of our development direction and architecture changes.

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.

Disadvantage is that every manufacturer does its web interface differently which makes administration of many printers of different brands awkward. In addition, automated printer administration with scripts requires different interfaces for each printer. And for setting local print queues you open your printer setup tool but for printer administration you have to open your browser.

To make this easier the Printing Working Group (PWG) has introduced the IPP System Service standard. This is an interface made up of standardized IPP requests to poll printer capabilities and configure the printer as needed. Every printer from every manufacturer uses the same requests and so a common printer configuration interface can be added to printer setup tools or automated administration with scripts is possible.

The student's task will be to create an appropriate printer configuration interface for system-config-printer or for the GNOME Control Center.

Mentors: Rithvik Patibandla (rithvikp98 at gmail dot com), Deepak Patankar (patankardeepak04 at gmail dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com), upstream developers of GNOME/GTK or system-config-printer TBD.

Desired knowledge: C and/or Python programming, GTK

Code License: GPL 2+ or LGPL 2+

The 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 CPD backend support for printing from Qt5 applications on support platforms.

Based on the GSoC work of the previous year, one example of Qt CPD implementation outside of Qt Print Support can be found at: https://github.com/rithvikp1998/CPDv2. For this task, the implementation is expected to start with QPrintDialog instead.

Mentors: Dongxu Li (dongxuli2011 at gmail dot com), Nilanjana Lodh, first implementor of the CPDB (nilanjanalodh at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C++ programming, Qt, CUPS

Licenses: Qt Contribution Agreement

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: Alexander Pevzner, “airscan” SANE backend author (pzz at apevzner dot com), Thierry Hucahrd, “escl” SANE backend author (thierry at ordissimo dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com, 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 + (L)GPL2 Exception (same as CUPS and PAPPL)

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.

As there are many multi-function devices (printer/scanner/copier all-in-one) which use the IPP, the Printing Working Group (PWG) has also worked out a standard for IPP-based scanning, “driverless” scanning, to also allow scanning from a wide range of client devices, independent of which operating systems they are running.

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.

Mentors: Alexander Pevzner, “airscan” SANE backend author (pzz at apevzner dot com), Thierry Hucahrd, “escl” SANE backend author (thierry at ordissimo dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com, Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), SANE upstream developers TBD

Desired knowledge: C programming, DNS-SD, IPP

Code license: GPL 2+

Traditional CUPS printer drivers consist of one or more print filters and a metadata file (PostScript Printer Description or PPD) which describes the printer capabilities, options, and filters. The filters convert common print formats such as CUPS Raster, JPEG, PDF, and/or PostScript into the printer's native data format for transmission to the printer.

Future versions of CUPS will do away with support for these printer drivers, choosing instead to package support for non-IPP printers in Printer Applications which provide IPP emulation - see the 2019 CUPS Plenary Slides. Some initial efforts have produced useful tools, including:

• ippeveprinter (part of CUPS for prototyping and supporting existing PostScript printers
• Printer Application framework from the Google Summer of Code 2019 by Dheeraj Yadav for classic (filters and PPD files) printer drivers (The framework itself, Snapping the Printer Application)
• LPrint for supporting DYMO and ZPL label printers
• PAPPL, a Printer Application framework/library based on ippeveprinter and LPrint

This year's GSoC goal is to get a universal Printer Application SDK (Software Development Kit) to not only convert classic drivers but also to create new printer drivers, from scratch, without PPD files.

The student's tasks here are

• Study Dheeraj's project and PAPPL to see from where the universal SDK can be started
• Check which functions are needed and which are already in existing projects (like CUPS/libcups, cups-filters, PWG's ippsample) to create a library, ideally in cooperations with the upstream projects.
• Create further needed code pieces, for printer discovery, starting of IPP service, passing jobs through driver and to printer, …
• Documentation and templates for designing the driver and making a Snap of the Printer Application.

Mentors: Dheeraj Yadav (dhirajyadav135 at gmail dot com), Michael Sweet, author of CUPS/LPrint/PAPPL and original creator of Gutenprint (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, DNS-SD, IPP

Code License: Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL)

Printer Applications are emulations of IPP printers on the local machine, usually to make a non-IPP printer work, the Printer Application being the printer driver. Printer Applications can also do other printing related things, like for example clustering remote IPP printers and when printing to the Printer Application, the most suitable printer will get automatically selected. Or a Printer Application can make IPP-over-USB printers work. Even CUPS is a certain form of Printer Application.

In the ideal case a Printer Application serving as a printer driver for example works completely automatically, auto-detecting the printers it supports and setting everything up, as creating the socket, registering the service on Avahi for DNS-SD advertising, …, and removing everything if the printer is disconnected or turned off.

This does not always work. For example for non-IPP network printers the user perhaps has to enter the IP address manually, or the printer driver can have configurable options which cannot be described in IPP attributes, or a Printer Application which clusters printers has to be told which printers to actually cluster, …

The Printer Working Group (PWG) has also create a standard for configuring IPP printers which we can use as well for emulated IPP printers, our Printer Applications. This standard is the IPP System Service. This allows to define configurable parameters which a device-independent client can poll from the IPP server and display in a GUI, so that the user can change them appropriate to his needs.

Curremtly, as the IPP System Service standard is still very new and there are no client GUIs implemented yet, IPP printers (and CUPS) use web interfaces, accessible with a web browser, for configuration. Not that comfortable and fast, and also very different from vendor to vendor. Also this could be implemented in Printer Applications to make them configurable.

The student's task is to create libraries, utilities, contribute to the Printer Application framework to get configurability in the Printer Applications. One could perhaps have two students, one for IPP System Service and one for a web interface.

Mentors: Dheeraj Yadav (dhirajyadav135 at gmail dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, DNS-SD, IPP

Code License: Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL)

cups-browsed is a daemon which discovers remote printers, mainly IPP but also legacy CUPS browsing, and makes them locally available. It gives a lot of possibilities for configuration, like clustering printers so that the most suitable for a job is automatically selected, allowing access to printers from legacy servers, showing only the relevant printers from thousands of printers available on the network, …

Currently it makes printers locally available by creating a queue on the locally running CUPS, and generating a PPD file for this queue. As PPD files in CUPS are deprecated and the support for them will soon go away, cups-browsed will have to follow, and the best way to do so, is to make a Printer Application from it. Instead of creating CUPS queues it will emulate IPP printers then, which get picked up automatically by CUPS.

The student's task here is to add IPP server functionality (icluding DNS-SD advertising) to cups-browsed. cups-browsed is already a Glib-based multi-function daemon, so adding a service should not be that much difficult. Nothing of the existing functionality should be removed, the user should be able to select between local queue creation or IPP server by the configuration file.

A plus, when there is time left, would be a configuration interface, ideally using IPP System Service.

Mentors: Deepak Patankar (patankardeepak04 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, IPP, CUPS

Code license: Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL)

cups-browsed provides nice features for big networks with many printers, as forming printer clusters, filtering the important printers out of thousands of printers advertised in a local network, and making available printers on legacy CUPS servers.

But on the other side cups-browsed has problems in networks with many printers, as it treats every printer it discovers one after the other and so it takes long until it has created local queues for all of them and it can also cause a high system load.

In this project the student should analyse the performance of cups-browsed with many remote printers and optimize it, using things like multi-threading for example.

And once splitting cups-browsed into threads, adding a form of in-process restart (on HUP signal and/or restart of CUPS) would be a plus.

Mentors: Deepak Patankar (patankardeepak04 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, IPP, CUPS

Code license: Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL)

With sandboxed packaging, Linux distributions appear which do not use classic RPM or DEB packages any more, like the all-Snap Ubuntu Core. And also standard desktop and server distributions, like Ubuntu Desktop/Server, will convert more and more to Snaps. Especially CUPS will also be moved from a classic package to a snap. Then CUPS will not work with classic PPD/filter-based printer drivers any more but requires all drivers being provided as Printer Applications.

Free software printer drivers can easily get converted, starting from rebuilding them to live inside a Snap, where everything is in other directories than in a usual system up to integrating its printer capability infoand filter algorithms directly into the IPP server daemon.

Proprietary, closed-source printer drivers come as binary RPM or DEB files, or tarballs, or even self-extracting. They require a certain, in classic systems usually available, file system structure to put their files in during installation, and they also need some libraries which are common in classic systems. In a snap you do not have this “standard” file system structure and the binaries with hard-coded paths in them choke on that.

A solution is to take the Printer Application framework and add a chroot to it. The proprietary driver will get installed in that chroot then.

The student's task is to add this functionality to the Printer Application framework and create an easy way for users to install proprietary printer drivers into that chroot-equipped Printer Application.

Mentors: Dheeraj Yadav (dhirajyadav135 at gmail dot com), Michael Sweet, author of CUPS (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, IPP

Code license: Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL)

Gutenprint is a printer driver for high-quality inkjet printing which is under continuous development for many years already and supports hundreds of printers. It is popular under users of both Linux and Mac OS X.

Currently, it supports printing either the classic CUPS way, by a PPD generator and a filter or by a plug-in for the GIMP. It should be rather easy to add more ways of using the core driver functionality, as this functionality is in a library, all capability information of the supported printers, dithering and color correction algorithms, …

The new mode of using this library should be a new Printer Application which will be the student´s task to create. The Gutenprint printer application should wrap the Gutenprint library and so support all the printers the library supports. The basic structure can be like the Printer Application framework but here we do not want to create the (deprecated) PPD files but instead, let the IPP server link directly with the library and serve out the printer capability information on client's get-printer-attributes requests. Also see Michael Sweet's work on PAPPL.

Mentors: Dheeraj Yadav (dhirajyadav135 at gmail dot com), Michael Sweet, author of CUPS/LPrint/PAPPL and original creator of Gutenprint (msweet at msweet dot org), Ira McDonald, OpenPrinting (blueroofmusic at gmail dot com), Smith Kennedy, HP (smith kennedy at hp dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gutenprint developers, TBD

Desired knowledge: C programming, IPP

Code license: (L)GPL 2+, Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL), MIT

Modern network multi-function devices (printer, scanner, fax) provide driverless operation (meaning no device/model-specific software or data is needed to use them). The device advertises itself on the network via DNS-SD providing a summary of its features and capabilities. Then a client can access the device using standard HTTP and IPP protocols to poll detailed capability info to be able to use the device and do the actual operation with the same communication protocols and standardized data formats for the images scanned or to be printed.

Current Linux distributions already support the printing part via IPP and there is also already upstream code for scanning via AirScan (eSCL) to appear in the distributions soon and the open IPP Scan standard is subject of another project in this GSoC. Also the standard for device configuration (IPP System Service) is subject of other projects in this GSoC list.

What is missing is IPP Fax out. This is a standard, very similar to driverless IPP printing for sending faxes. Principally sending a fax can be done by printing a file to a special destination in the device, accompanied with a phone number (required) and some fax-specific options (like how to proceed on failure or cover sheets, …) as IPP attributes.

One can easily determine whether a device supports this and poll all needed capabilities. The DNS-SD record of the device's printing part (“_ipp._tcp”) does not report only the URI extension for printing (“rp=ipp/print”) but also for fax (“rfo=ipp/faxout”, no extra DNS-SD record!). If there is such an entry one can poll the URI “ipp://host:port/ipp/faxout” with a get-printer-attributes IPP request as it was a printer, and one gets the capabilities for the device-internal fax destination. The “driverless” utility of cups-filters happily generates a PPD from this, but naturally without fax-specific options, and if you create a CUPS queue with this URI and PPD and print a file with “lp -d queue -o phone=0012345678 file” the device will fax the file to the given number. The feature is commonly available in modern devices and I have actually tested it as described here.

The student's task here is to make this functionality easily accessible for users of common desktop Linux distributions. Like printers, faxes should automatically appear on the system and get available in print dialogs and if one prints to a fax, fax-specific options should also appear in the print dialog and the user should be able to pick phone numbers also from contacts.

This can be done by expanding existing resources and creating new ones in the printing stack. Especially one should think here abour the Common Print Dialog Backends (CPDB), but also other projects, like cups-filters would perhaps need changes.

Mentors: Nilanjana Lodh, first implementor of the CPDB (nilanjanalodh at gmail dot com), Dongxu Li (dongxuli2011 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C/C++ programming, CUPS, IPP

Licenses: MIT, Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL), GPL 2+

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.

To make these algorithms available for other printer setup tools (both interactive GUI tools and programs which fully automatically create print queues without user interaction) they got moved into a D-Bus service, scp-dbus-service. Now every other program can simply call the needed function via a D-Bus API. The printer setup tool in the GNOME Control Center for example works this way.

GNOME Control Center uses two methods - GetBestDrivers and MissingExecutables - for its printer setup. The GetBestDrivers method is used for finding the right printer drivers from ones which are available on the system. The MissingExecutables method is checking method, which is run after finding the best driver and checks if any additional software is needed for getting the printer functional.

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 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)

Desired knowledge: C/C++ programming, Python programming, autoconf/automake(creating configure and Makefile), basic testing

Code license: GPL 2+ or MIT

If an incoming print job is a PDF file and the printer is not a PDF printer, the file always goes through a PDF interpreter (Ghostscript, Poppler, or MuPDF) to get rasterized. This is needed when the file contains vector/high-level graphics, fonts, …, but is unneeded and can even produce bad interferences if each page is a simply a full-page bitmap (raster graphics).

There is even an official file format, PCLm, which is a subset of PDF but describes each page as full-page raster graphics. It is used for driverless printing on cheaper printers which do not provide a PDF interpreter. As the files are a subset of PDF, they are recognized as PDF format. Also certain PDF from scanning software (or hardware) are raster-only.

To speed up the filtering process and to avoid quality degradation caused by mis-matched resolutions we could recognize these special-case PDFs, extract the bitmaps from each page and convert them into PWG/CUPS Raster and then continue as we had gotten raster graphics in the first place.

We could let the pdftoraster/gstoraster filter (or already CUPSvia MIME types) identify whether the input is PCLm (or any other known raster-only PDF format) and in this case delegate to a pclmtoraster filter to extract the raster data from the pages and convert them into other raster formats, without PDF interpreter.

The student's task here is to find out about suitable raster-only PDF types (at least PCLm should be supported, the more file types, the better), make these files get identified, and write a CUPS filter which extracts the raster data and passes it on as CUPS Raster. The resulting code will get added to the cups-filters project.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, CUPS

Code license: (L)GPL 2+, Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL), MIT

Currently, most probably due to the fact that once most printers use paper in cut sheet and also PPD (PostScript Printer Description, now deprecated) files only support paper in cut sheet, roll paper as used in large-format and also some specialty prrinters is not actually supported.

The difference of roll paper against sheet paper is that only its width is defined, the height of the printing area can be selected individually for each print job.

What the user expects to happen is that the paper is cut right after the page so that nothing is wasted and the user has minimum work with manual cutting. He also would like pages to be rotated by 90 degrees if they fit better this way, for example if the page height fits into the roll's width. This saves paper and allows pages which are too wide for the roll to be printed. An option to activate this (auto), never rotate, or always rotate should be added.

Also some way to manage paper consumption and preventing a page being started which does not fit into the remaining paper is desired.

The student's task is to add this functionality into the current print workflow.

He should at first study the IPP (Internet Printing Protocol) standard for its roll paper support. Then he should check where changes are needed: in CUPS, cups-filters, print dialogs … Also it has to be investigated whether this can be completely implemented in the current (deprecated) PPD-based printing workflow or whether the new Printer-Application-based model is required.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, IPP

Code license: Apache 2.0 + (L)GPL2 Exception (same as CUPS and PAPPL)

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

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.

Here the student's task is to add this functionality to a popular file manager, for example the one of GNOME.

Mentors: Aveek Basu (basu dot aveek at gmail dot com), upstream developers of GNOME/GTK TBD.

Desired knowledge: C programming, GTK

Code License: LGPL 2+

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/~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/~ajohnson/inkscape/log/?h=color-space Also see http://lists.cairographics.org/archives/cairo/2012-July/023353.html and https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for more details.

Expectations: The cairo and inskcape code is pushed upstream with any required modifications. Ideally someone familiar with the cairo community would take this on, as Adrian found it hard to get the code approved upstream.

Skills: Understanding of basic color management, basic use of bzr and git, proficient in C.

Contact: Richard Hughes (hughsient at gmail dot com)