OpenPrinting Summit - Print Dialog and Colour Management
johnlayt at googlemail.com
Thu Mar 17 10:36:14 GMT 2011
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
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
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
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.
More information about the kde-core-devel