The Linux Foundation

 
Google Summer of Code

From The Linux Foundation

This is our list of project ideas for the Google Summer of Code program in 2008. We got 48 student applications in the two weeks of application period and they are covering all our suggested project ideas. We got 8 student slots from Google and 5 students are currently working on OpenPrinting projects and 3 on kernel projects.

Thanks to all the students who have applied, to everyone who stepped up to take mentorship, and naturally to Google.

Contents

OpenPrinting

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

OpenPrinting developer resources

PAPI integration in CUPS

Cherif YAYA is implementing this project.

PAPI is an application programming interface (API) that allows applications to interact with a print service or print services in a service and/or protocol independent manner. It supplies functions for enumerating available printers, sending print jobs, querying printer capabilities, listing jobs in the queues, ..., and all this independent of the printing system/spooler actually used.

This interface is already implemented for the LP printing system on Sun's Solaris operating system (version 9u6 and later). There are also free software client tools, like command line commands, protocol listeners, ... See the OpenPrinting SourceForge project site.

Under Linux CUPS is the de-facto standard printing system, used by all important Linux distributions. The problem for PAPI not getting widely used under Linux is that there is no CUPS integration of PAPI. And solving this problem is the goal of this student project. A PAPI backend library has to be written which allows application programmers to access to the printing resources via PAPI and CUPS to provide maximum functionality through this interface.

Applications doing printing via PAPI can be built without source code changes on all systems which provide PAPI, independent which printing system they use (Linux, Solaris, embedded, ...).

The PAPI backend library will either be added to the PAPI package on SourceForge or it will be part of CUPS itself.

Mentor: Norm Jacobs, Sun (norm dot jacobs at sun dot com)

Desired knowledge: C Programming

JTAPI implementation

We have no student working on this project. Volunteers welocme!

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. These job tickets do not only make sense for large-scale production printing, they are also useful for mobile devices, home desktops, workgroup printers, ... Also access to print services on the internet directly from the desktop applications simply via a print queue would be possible.

To allow desktop applications, printing systems, and printer drivers to easily create, edit, and read job tickets without needing to deal with the actual job ticket format, the job ticket application programming interface (JTAPI) was developed by OpenPrinting. A complete specification is published.

The next step to do is the actual implementation of the JTAPI library and its integration in applications, the CUPS printing system, drivers, filters, ... This will be the task of the student in this Google Summer of Code project.


Proposed Tasking:

Objective: Using the header files created by the Open-Printing Job-Ticket Working Group develop a platform independent C library for the reading-of, modification-of and storage-of a print job ticket for the Printer Working Group’s (PWG’s) Micro-Job-Ticket (MJT).

Approach:

  1. Review OP/JTWG Job-Ticket Application Programming Interface (JTAPI)header documents
  2. Review PWG/MJT specification.
  3. Create Test MJT’s
    1. Manually create a minimum of 3 representative MJTs (text files) to be used for testing and evaluation
  4. Define the command-line Test Application to exercise the JTAPIs; include an initial set of commands
  5. Create Thin-Thread implementation of the individual JTAPIs and the Test Application.
    1. This will be the first demonstrational implementation and the start code for detailed development.
    2. This will include minimum documentation on how to use the Test Application
  6. Enhance individual JTAPIs and the Test Application to provide full functionality.
    1. Provided update documentation as required.
  7. Project Demonstration.


Code License: MIT

Coding Language: Platform Independent C (No platform or vendor-specific extensions)

Coding Document: In-line commenting must be sufficient to understand the flow and any section requiring extended understanding.

Operating System: Student’s choice – Linux or Windows (non-gui for either)

Interface: Command Line – GUI not required unless very simple (due to project time constraint)

Document: Minimum:

  1. How to build the JTAPI library.
  2. How to build the Test Application
  3. The Test Application command-line instructions
  4. Three examples of using the Test Application and exercising the JTAPIs


Mentor: Glen Petrie, Epson (glen dot petrie at eitc dot epson dot com)

Desired knowledge: C Programming

JTAPI JDF Job-Ticket Implementation

We have no student working on this project. Volunteers welocme!

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. These job tickets do not only make sense for large-scale production printing, they are also useful for mobile devices, home desktops, workgroup printers, ... Also access to print services on the internet directly from the desktop applications simply via a print queue would be possible.

To allow desktop applications, printing systems, and printer drivers to easily create, edit, and read job tickets without needing to deal with the actual job ticket format, the job ticket application programming interface (JTAPI) was developed by OpenPrinting. A complete specification is published.

This is a parallel project to actual implementation of the JTAPI library by providing a JDF Job-Ticket Front-End. This will be the task of the student in this Google Summer of Code project.


Proposed Tasking:

Objective: Using the header files created by the Open-Printing Job-Ticket Working Group develop a platform independent C module for accepting, parsing, interpreting and translating JDF Job-Tickets to JTAPI objects/attributes using the JTAPI's.

Approach:

  1. To Be Determined


Code License: MIT

Coding Language: Platform Independent C (No platform or vendor-specific extensions)

Coding Document: In-line commenting must be sufficient to understand the flow and any section requiring extended understanding.

Operating System: Student’s choice – Linux or Windows (non-gui for either)

Interface: Command Line – GUI not required unless very simple (due to project time constraint)

Document: Minimum:

  1. How to build the JDF Job-Ticket Module.
  2. How to build the Test Application
  3. The Test Application command-line instructions
  4. Three examples of using the Test Application and exercising the JTAPIs


Mentor: Glen Petrie, Epson (glen dot petrie at eitc dot epson dot com)

Desired knowledge: C Programming

PDF as the standard print job transfer format: CUPS filters for PDF handling

Tobias Hoffmann is implementing this project.

One of the decisions which was made on the OSDL Printing Summit in Atlanta last year and widely accepted by all participants was to switch the standard print job transfer format from PostScript to PDF. This format has many important advantages, especially

  • PDF is the common platform-independent web format for printable documents
  • Portable
  • Easy post-processing (N-up, booklets, scaling, ...)
  • Easy Color management support
  • Easy High color depth support (> 8bit/channel)
  • Easy Transparency support
  • Smaller files
  • Linux workflow gets closer to Mac OS X

The switchover to PDF as standard print job format is work in progress. For CUPS appropriate filters are already under development and some of them are available in the Subversion repositories of the OpenPrinting Japan SourceForge site.

Not all filters are written yet. Missing are the texttopdf filter to print plain text files and the pdftoijs filter to couple IJS plug-in drivers (like HPLIP or Gutenprint) with a PDF renderer. This project is about writing these two filters and testing them. The filters will then be made part of CUPS.

Some more background information is in [1]


Mentor: Hin-Tak Leung (HinTak dot Leung at gmail dot com), author of several drivers for printers with proprietary protocols

Desired knowledge: C programming

Common Printing Dialog: Coding on the dialog designed by OpenUsability, for KDE and/or GNOME

Alexander Wauck is implementing the dialog itself.
Lars Uebernickel is developing a plug-in interface between application and printing dialog (CPDAPI).

At the OSDL Printing Summit in Atlanta in April 2006 usability experts from OpenUsability were present and kicked off the design of a common printing dialog for all desktops and applications under Linux. This dialog is once designed with usability in mind, studies about potential user groups and printer types were performed, paper prototyping and interaction design done, ... and second, the overall usabilty of Linux will be improved by having the same printing dialog everywhere.

Now, near two years later, the design is completed and specifications for the dialog and its integration are in the works. Based on these specifications driver developers/printer manufacturers will be able to fit their drivers to the dialog and application and desktop programmers will be able to implement the common dialog.

The candidate's task will be to turn the dialog live for the first time. He will do a first implementation following the specifications and he will test this dialog with different applications, and drivers/PPDs. With this he will test the dialog concept and the specifications. He will enter in contact with the OpenUsability people and with desktop developers from KDE and GNOME. The code will also be supplied to OpenUsability to finally test their design.

In the end of May, just when the coding period of the Google Summer of Code starts OpenPrinting and OpenUsability will hold, together with developers of KDE and GNOME a printing dialog kick-off meeting in Berlin, just before the LinuxTag. We will try to get the candidate onto this meeting.

At July 8, 2008 (when the mid-time evaluation at the Google Summer of Code takes place) their will be an OpenPrinting Meeting in Tokyo where the common printing dialog will be presented to the Japanese printer manufacturers and to the Japanese Linux Foundation members. So at this time the first working version will be needed. The rest of the time is for more polishing, debugging, and testing, and also for integration of the dialog with applications.

We can take 2 students here, one working on a KDE, another on the GNOME version. The best would be if a student writes a dual-interface hybrid version with GUIs for both KDE and GNOME (like the Ubiquity installer of the Ubuntu/Kubuntu desktop CDs).

Mentors: Josef Spillner, KDE, automatic GUI generation (josef dot spillner at googlemail dot com), Jonathan Riddell, Kubuntu, dual-GUI (KDE/GNOME) applications (riddell at gmail dot com)

Desired knowledge: C/C++, GUI programming with Qt and/or GTK

OpenPrinting database: Web-based (CGI) software for reviewing and triaging user-contributed printer entries and comments

Subhankar Sett is implementing this project.

The OpenPrinting database is the principal source of information about which printer work how well with Linux and how one gets them actually to work. The database is not only available on the OpenPrinting web site but also locally installable and most Linux distributions have it locally installed to provide the printer model and driver information to their printer setup tools and to integrate the printer drivers with the printing system (usually CUPS).

Very many entries were formally gathered by a web input form where users could tell about the Linux experience with their printers. As this form of data gathering was very efficient, the web form was re-introduced some time ago. This way we quickly gathered several hundreds of new printer entries, but unfortunately, they are only visible on the OpenPrinting web site, as they are only present in a Wiki-like auxiliary database and not in the main Foomatic database which is downloaded and packaged by the Linux distributions. Only proofread and verified entries are supposed to be transferred into the Foomatic database, as the Foomatic database is a core part of the Linux distributions and users and commercial support rely on it.

Reviewing and triaging these printer entries and also the user comments which can be given on printer entries is a lot of work, especially also when the information needs to be moved into the Foomatic XML database manually. To facilitate this, one needs an application, which allows to browse through all new printer entries or comments, and shows buttons to add the entry to a copy of the Foomatic database, delete it, hand-edit the new or modified Foomatic entry, find entries with similar names, ... In the end a patch of all changes on the Foomatic database should be generated and uploaded into the Bazaar repositories of the Foomatic database.

This would be preferably done as a CGI application running on the server on which the OpenPrinting database is running. This way a moderator (who logs in with his Linux Foundation credentials) could quickly triage new entries to get the good ones quickly into Foomatic and the bad ones quickly deleted to finally get the valuable user contributions into the Linux distributions.

Mentor: Till Kamppeter, OpenPrinting manager and maintainer of the OpenPrinting database and Foomatic software (till dot kamppeter at gmail dot com)

Desired knowledge: XML, HTML, CGI programming, Perl, printing under Linux

vendor WIN32 driver made available to linux applications

We have no student working on this project. Volunteers welocme!

There was a Google Summer of Code 2007 project under wine [2] to use WIN32 drivers to print from wine, and some adaption of that idea in some limited fashion in ddiwrapper [3]. It would be quite interesting and useful to properly integrate this into the more general printing workflow:

  • make it possible to print from linux applications through cups or other spoolers with more(all?) WIN32 drivers

Currently there are two(?) frameworks which are usable for loading binary-only closed-source vendor driver modules, OPVP and IJS. There are a few other FOSS projects which uses some part of wine to load binary-only WIN32 modules for accessing data in proprietary format quite successfully - e.g. ndiswrapper (for wireless network hardware), mplayer (for multimedia playback).

Some background information is in [4]

Mentor: Hin-Tak Leung (HinTak dot Leung at gmail dot com), author of several drivers for printers with proprietary protocols ; Detlef Riekenberg from the Wine Project, who was the mentor for the Gsoc 2007 wine project for print proxy, has agreed to be involved.

Desired knowledge: C programming

The Linux Kernel

Linux kernel participates in association with KernelNewbies so you can also look at the KernelProjects page there.

kmemtrace - Kernel Memory Profiler

The purpose of kmemtrace is to provide kernel memory profiling tools to developers for optimizing kernel memory usage and analyzing the memory efficiency of the current SLUB and SLOB allocators. The project consists of two parts: (1) add tracing to kernel memory allocator kmalloc()/kfree() functions using relayfs or similar mechanism and (2) write user-space tools for analyzing that information. Note: we also need boot-time profiling which relayfs does not currently support, so you might need to do some work on the tracing infrastructure too.

Mentor: Pekka Enberg, SLAB allocators, memory management, file systems (penberg at gmail dot com)

Desired knowledge: C, Python/Perl, kernel memory management

Real Time Kernel

The Pre-emptive Real-Time Linux kernel patch adds the ability for the Linux kernel to function as a "Real Time kernel". To do this, many changes are made to the kernel (such as the replacement of spinlocks with sleeping mutexes). Many of these changes have yet to make it "upstream" into the official kernel tree, but there are numerous pieces of the RT kernel that would benefit even regular Linux kernels. To this end, there are a few specific features that are in the RT kernel at this moment that need cleaning up for release into "mainline" Linux. These include threaded interrupts, threaded tasklets, and other components. This will aid eventual upstream acceptance of the Real time patches.

Mentor: Jon Masters, Red Hat (jonmasters at gmail dot com)

Desired knowledge: C, Linux kernel, Real Time

Driver Backport

Mailing list: Lf_driver_backport at lists dot linux-foundation dot org

Driver Backport developer resources

The driver backports group is working on tools and technologies to allow multiple Linux distributions to use automated driver update tools in order to detect available hardware, and downloaded (updated) drivers for that hardware, built to run on a particular Linux distribution. The goal is to make life much more comfortable for end users of modern Linux systems, since they can rely upon their Linux distribution to provide driver updates automatically, without requiring users to build their own Linux kernels or constantly run the most "bleeding" edge software.

Creation of an online driver database for automatic driver package download

We are seeking 2 developers to assist with the creation of an online driver database, which will maintain information about known third party drivers for Linux systems, along with the interfaces for third parties to securely interact with the database, add and update their entries, and so forth. Candidates with additional experience in both Linux kernel and driver development would also be expected to assist with testing and implementation of the client tools.

Mentor: Jon Masters, Red Hat (jonmasters at gmail dot com)

Desired knowledge: Python, Apache (especially modpython), LAMP. Additionally, strong C programmers with experience in Linux kernel development able to also assist on the client tools themselves would be a strong plus.


[Article] [Discussion] [View source] [History]