OpenPrinting Summit - Print Dialog and Colour Management

[John Layt]

On Wednesday 16 Mar 2011 23:27:04 Christoph Feck wrote:
> Many thanks, John, for never giving up with improved printing in KDE!

Thanks, I may not be the most effective hacker around, but I am persistent :-)  

Just to be clear, I'm not saying we will go with the CPD, that's not a 
decision I can make, but I want to make sure we've fully explored the option 
as this is one Linux infrastructure project that is wanting our involvement 
and actively working to ensure we get equal treatment.

> First, regarding the "common" part of the printing dialog, I hope that
> using a common denominator of features offered in all operating systems
> does not reduce the feature set again; we already went through it. (I
> guess you know the existing bug reports. It boils down to the major
> feature loss that we got when killing KDE 3.x printing system.)

Ah, actually the CPD isn't cross-platform, it's cross-desktop meaning the same 
dialog design and back-end code used in both Gtk and Qt apps.  If you're 
running a KDE app on a Gnome desktop you'll get the Gnome dialog pop up for 
consistency with the rest of your Gnome apps, but using the same common 
backend.  Personally, I'm not sure it is consistent to have a KDE app pop up a 
Gnome dialog, but we'll see.

It's all CUPS based and supports the full set of CUPS features, and will also 
"magically" support all the extra settings that the printer has via an 
enhanced set of PPD definition files.  In fact a big driver behind the CPD are 
the printer manufacturers who want full support for their products in the 
dialog.

In theory, porting it to OSX wouldn't be a problem as OSX uses CUPS as well, 
but the native OSX dialog provides all the needed features anyway so it seems 
a little pointless.  Windows would be next to impossible to support.  So a 
major point of mine will be that any implementation needs to degrade 
gracefully to the standard Qt print system, and to gain client apps in the 
wider Qt world they will need to address the issue.

Actually, I am a little concerned about the Gnome side of things, OpenPrinting 
missed the boat with the Gtk3 release, and there's noises now coming from a 
certain Gnome dev that he doubts it will get adopted, especially as the dialog 
design breaks their HIG.  Worst comes to worst, we may not get a common 
backend or look-and-feel, but we'll get agreed standards on the PPD and colour 
management integration into the dialog which we can implement in Qt.

> The new printing dialog should not be shy on options, such as pamphlet
> printing, customizable filters, and (most importantly) application specific
> options with the ability to allow saving settings in global or application
> specific profiles.

Yep, the settings management comes built-in to the dialog, if you've ever used 
the OSX dialog it's clearly inspired by that.  As for pamphlets and filters, I 
don't think they are supported as yet, but as it is an entirely pdf/ps based 
workflow adding them is definately an option, unlike with Qt.

The best place for pamphlet support is in CUPS itself, but it's proving 
difficult to get in there so a filter remains the best short-term option.

> The second concern is about the D-Bus API. I hope that it will still be
> possible to get a fast in-application preview with it when using the native
> API.

Yes, I have some concerns about the whole D-Bus thing, there's argments for 
and against doing it that way.  What I'm hoping is whatever API and library 
gets implemented abstracts away the backend implementation so we have the 
option of pulling it all back in-process if it proves too inefficient or Gnome 
doesn't play along.

> For example, I love how the current Qt printing preview dialog just copies
> image pointers in the QtPrinter painting engine, so that the preview
> renders literally the same images as the application has in memory,
> without copying the actual data. The Qt printing preview is also very fast
> in scrolling and zooming, I doubt it would be possible with a program that
> effectively "just" tries to parse PostScript or PDF printer files just to
> generate the preview.

The current KPrintPreview and QPrintPreviewDialog will still be an option, but 
they won't integrate well with CPD.  QPrintPreview in particular will know 
nothing about the CPD unless Qt adopts it.  For most apps the CPD preview 
using poppler would be fast enough, will reflect the full set of page 
manipulation options available, and be a simpler workflow.

I do like how smoothly QPrintPreview works, I just wish Qt had finished the 
job by merging it more with QPrintDialog and supporting all the CUPS options 
in a cross-platform way.

Another issue with QPrintPreview (and QPrinter in general) is the Okular case, 
where what is rendered by the app on screen is a far lower resolution version 
of the actual document than what you want printed.  If QPrinter supported 
taking a print file then it could be worked around.

The CPD does allow you to pass separate preview and print versions of the file 
which may make display rendering faster at the expense of rendering the 
document twice.

Anyway, I'll try push patches for Qt again and maybe in a years time we'll 
have the luxery of choosing between two good options.

> Kai-Uwe Behrmann (maintainer of KDE color management applications) can
> help you here. Grab him on http://www.oyranos.org/ and make sure he attends
> the meeting ;)

Ah, now there's something I didn't know about.  I guess we need to raise its 
profile more and see what help Kai-Uwe needs.  It's a whole new world for me, 
but it's nice to know we already have KDE people there.

Cheers!

John.