CommonPrintingDialog

Summary

All applications should have the same print dialogs with the same parameters to adjust. All systems (Kde/Gnome...) should manage CUPS printers in the same way. System printers and parameters and also user parameters must be manageable.

The idea of the Common Printing Dialog designed by OpenUsability was brought in on the OSDL Printing Summit in April 2006 and work was continued on subsequent Printing Summits.

The Common Printing Dialog is one of the main projects of OpenPrinting at the Linux Foundation, coordinated by Till Kamppeter, manager of OpenPrinting.

Rationale

If a user knows how to print out of application A he will also know how to print from application B. He also will have access to all the features of his printer and of CUPS from all applications.

Use cases

  • LaserStar Electronics in Japan wants to publish Linux/Unix printer drivers for their wide range of printers, beginning from 30-EUR-cheapo inkjets over 256-ink high-end photo-printers, up to 30-pages-per-second color laser office multi-function devices. They want all users to have easy access to the full functionality of their devices from all applications. Their devices support Locked Print (user can only pick up his printout when entering a password which she has sent with the job, so that Lea cannot see Lisa's confidential printout), color adjustment (numerical parameters), fax (phone number), ... And they want to place their logo in the printing dialog.

  • Lisa wonders why she can't print 2 pages per sheet directly from OpenOffice.org. She always has to export to PDF and then print with evince.

  • Lea from Germany likes the fact that OpenOffice.org's printing dialog offers her so many options, but she wonders why all the options are in English. Furthermore she thinks that it isn't very easy to use.

  • Lara wants to print a photo in gThumb. After that she wants to print some notes in gedit and some labels using gLabels. She dislikes the fact that she has to change the resolution for every task using system-config-printer.
  • Laura has an Epson printer. She wants to know the ink-level and clean the heads, if necessary. She finds out that this can be done using escputil, which is included in Gutenprint. She installs escputil via apt and also finds out about mtink, which has an ugly GTK1-GUI, that doesn't suit to her KDE-Desktop. She would like to have the features of escputil in system-config-printer or in the printing dialog. She also thinks it would be nice for new users to have a button in every printing dialog for doing these advanced tasks.
  • Lena has installed Adobe Reader from Multiverse. She likes the preview andwant s to have it in the other applications.
  • Bob and Jane wonder why there are so many names beginning with "L"

Scope

All desktops on all Posix-style operating systems. As a first step we will cover at least KDE and GNOME.

Design

OpenUsability has designed a GUI for the Common Printing Dialog starting in 2006. It is based on paper prototyping, discussion on Printing Summits, surveys, and the work of usability and user interaction specialists.

It has an all-time visible preview, quick preset buttons (for things like "Draft", "Office document", "Photo", "Booklet", ...), and detailed printing options can be shown or hidden by category ("Paper handling", "Resource saving", "Finishing", ...).

General info about the UI design of the Common Printing Dialog:

The interface between the applications and the dialog will be done via D-Bus. It will be written a glue code which replaces/patches the libraries which the applications call to open their original printing dialogs. This glue code calls the Common Printing Dialog via D-Bus then. With this glue code we do not need to modify all applications. Making the glue code for KDE/Qt, GNOME/GTK, and OpenOffice.org will switch most applications to the new printing dialog. Note that the newest version of Firefox already uses the GTK printing dialog, so Firefox will also be covered by modifying the libraries for GNOME/GTK applications. Perhaps Thunderbird needs to be modified, too.

Extensions for PPD files are designed to support advanced UI functionality as needed by the drivers (printer manufacturers). First of all, the custom PPD options as described in the documentation of CUPS will be used, to allow numerical parameters, strings, passwords, ... as printing options. There will be also definitions for the quick presets, the categories to which the options belong, and UU-encoded icons and logos. Printer manufacturers and independent driver projects will use this functionality to present the options of their drivers/printers on the dialog.

Implementation

In the summer 2008 the dialog implementation was started by two Google Summer of Code students:

1. Lars Uebernickel is implementing a DBUS-based interface for the Common Printing Dialog

2. Alexander Wauck is implementing the GUI of the Common Printing Dialog itself

In the summer 2009 the work was continued as Google Summer of Code projects:

1. [[http://socghop.appspot.com/student_project/show/google/gsoc2009/linux_foundation/t124022665328|Per Hermansson will finish the implementation of the GTK GUI of the Common Printing Dialog}}

2. Alexander Wauck will implement the Qt GUI of the Common Printing Dialog

Independent of this, Lars Uebernickel is working on patching the GTK and Qt libraries for a first stage of a Common Printing Dialog. This first stage is not based on OpenUsability's dialog, but simply introduces the D-Bus interface into the Qt anmd GTK libraries and so at least a user of the GNOME desktop will get the GTK dialog, independent if the application is GTK- or Qt-based and the KDE user will always get the Qt dialog.

All changes will be applied upstream, as the project is intended for all distributions.

Here are the specs:

The specs are principally complete. Small changes are possible if required by the implementation.

A first prototype of the dialog and the specs were presented to the Japanese printer manufacturers on the OpenPrinting Meeting on the Linux Foundation Japan Symposium in Tokyo on July 8 by Till Kamppeter and Peter Sikking. Peter Sikking has also presented the dialog to the GNOME developers on the GUADEC in Istanbul.

Here are some remarks about the replacement of the printing dialogs by the D-Bus interface to the Common Printing Dialog in applications:

For generic GNOME and KDE applications the dialog should be replaced by modifying the GNOME and KDE library functions which call the original printing dialog. Main problem here is that some apps customize the printing dialog by inheriting the printing dialog class and extending it.

Firefox 3.x and Thunderbird 3.x use the GTK printing dialog currently, so they will be covered by the change of the GNOME/GTK libraries.

Red Hat/Fedora patches OpenOffice.org to use the GTK dialog. This patch shows where OOo gets changed fo replacing its printing dialog and so it can be a base for replacing OOo's original dialog by the D-Bus interface to the new dialog. In a first approach one could use the patch as is and when Lars modifies the GTK/GNOME libraries to get the new dialog into the GNOME apps, it will also appear for OOo. But we must rather modify the patch to do direct calls to the new dialog's D-Bus interface instead of GTK lib calls, so that we do not pull the GTK libs onto the Kubuntu live CDs (and space-limited KDE-based distros in general).

Code

The code for the Common Printing dialog is hosted at OpenPrinting.

Browse the code for the dialog's UI on

http://bzr.openprinting.org/devel/common-printing-dialog

Download it with

bzr branch http://bzr.openprinting.org/devel/common-printing-dialog

To compile and run, do 

mkdir build
cd build
cmake ..
make
kde4-dialog/kde4-cpd &
kde4-dialog/view-dialog --previewfile <PDF file> &

<PDF file> will be used for the preview. On Hardy use the following "cmake" command: 

cmake -DCMAKE_INSTALL_PREFIX=/usr/lib/kde4 ..

Browse the code for the D-Bus interface between the applications and the printing dialog (CPDAPI) here

http://bzr.openprinting.org/devel/cpdapi

and download it via

bzr branch http://bzr.openprinting.org/devel/cpdapi

To test the code, run the following commands (the packages "cmake" and "libqt4-dev" must be installed, qmake must point to the Qt4 version, remove the package "qt3-dev-tools" or do "update-alternatives --config qmake"): 

mkdir build
cd build
cmake ..
make
qt-dialog/qt-dialog &
qt-client/qt-client
qt-dialog/qt-dialog &
../simple-client.py

Data preservation and migration

Outstanding issues

Get the continuation of the development funded.

BoF agenda and discussion

UDS Maverick:

  • Continuation of the development and funding

Notes from UDS Intrepid discussion:

1st Meeting 

Here are some quesitons and comments which came up during the printing meeting 
at UDS. I may have missed some comments, so whoever was there may feel free 
to add.

---

Tags for printing options: what is the official list and what options belong 
below each of these tags. Are there any plans to test the tags and their 
options?  Will they work for most use cases?

The idea of being able to turn off and on pages in the preview was discussed.  
The user could scan the preview pages and decide if they want to print it or 
not by a checkbox or other interative method.

Preview generation: If there is a refresh of the preview needed, provide an 
intermediary image ("Loading.." message or whatever) until the preview data 
is available.  This would only happen sometimes, when there are many pages 
for transformation or the transformation takes some time

There were some questions about the hierarchy of quick presets and control 
printing aspects and how they effect each other.  It wasn't clear right away 
how the one would effect the other.

Have there been any considerations for Mobile devices? Will the dialog scale 
and work on smaller screens?

Are there any accessibility concerns about the new interaction methods being 
used?  Can everything be made accessible?

How do the application specific options integrate in to the dialog?  Will they 
be visible by default for the user to configure, or will they have to call 
them explicitly?

2nd Meeting 

https://blueprints.launchpad.net/ubuntu/+spec/applications-printing
https://wiki.ubuntu.com/PrintingStandardization

The Common Printing dialog is for Posix systems using Cups.
Programs like Firefox should continue to use the native print dialog on Windows.

Fedora has patched Open``Office.org to use the common printing dialog.

Some applications currently customize their platform-specific dialog (e.g. Firefox adds an "Options" tab to the GTK dialog). These will need altering to adapt their customizations to the common printing dialog.
 * This implies a standard interface by which applications can say what controls they want, with these being rendered as GTK/Qt controls in the appropriate place in the dialog.

Thunderbird currently uses its own printing dialog.

Firefox, Thunderbird and OpenOffice have a plug-in architecture to use the GTK2 "Save As..." dialog.  It results in optional support packages such as firefox-gnome-support, thunderbird-gnome-support, openoffice.org-gnome, xulrunner-1.9-gnome-support, etc. Would the right approach for a common printing dialog be that we submit patches to upstreams to implement a similar plug-in architecture for the printing dialog? Then, GTK2-based and QT-based desktops could install appropriate packages for these applications e.g. firefox-gtkprint-support, firefox-qtprint-support, etc.
 - it'll likely be more complex due to preview images, callbacks might be needed
 - non-technical: Mozilla Foundation doesn't like such changes, talk to them
 - True, but they have recently been more collaborative on e.g. letting DE's use their own toolkit such as in FF3.

We need to contact upstreams to get them to hook in to the common dialog, but this might be difficult until there is working code. Perhaps have one GTK and one Qt application hooked up as examples.

July 8th: milestone for prototype and final specification. Can then be presented at Guadec and Akademy.

Optimistic to have this implemented across most applications for Intrepid.

How will non-GUI applications (e.g. command line tools or cups-pdf) access the same features?
 * There will need to be a command-line equivalent, like lp/lpr.
 * cups-pdf offers the possibility of defining a post-processing command, in the configuration file, which could be used to pipe the PDF printout to the GTK2 or QT "Save As..." dialog, via a simple command line tool that is dbus-enabled. This would avoid having to implement this as a ./configure option for cups-pdf, so that upstream code continues to exist as a pure printer driver.

Further discussion

Discussion places for this project are the printing-architecture mailing list at OpenPrinting (See especially also its archives) and the #openprinting IRC channel on irc.linuxfoundation.org (tkamppeter = Till Kamppeter, guiguru = Peter Sikking, larsu = Lars Uebernickel, waucka = Alexander Wauck).

Acknowledgments

We thank especially HP and Konica Minolta for the financial support of OpenPrinting. We also thank Epson for funding Peter Sikking's travel to Tokyo, Istanbul, and San Francisco. We thank Ricoh for funding Lars Uebernickel's travel to San Francisco. We thank Google for funding the student projects.

CategorySpec

CommonPrintingDialog (last edited 2010-05-07 08:24:14 by p5DDB9EB9)