KDE4 printing: results of IRC meeting

John Layt johnlayt at yahoo.com.au
Thu Sep 13 19:56:56 BST 2007

Generally speaking, I'm in favour of the option of a short-lived minimal 
KPrinter/KPrintDialog/KPrintPreview API inherited from Q, move kcm to kdebase 
for development in 4.1, and working with the trolls to ensure 4.4 has what we 
need in 4.1.

First, a definition of some terms and features as I understand them:

The object that does the actual printing work. Found in kdelibs/kdeprint.

The dialog box that gets displayed when choosing File/Print from the
menu or kprinter from the command line. Found in kdelibs/kdeprint.

Command line program that takes a file or stream, displays the KPrintDialog 
for user interaction, then prints.  Found in kdebase/kprinter.

Printer System:
Systems that manage the printing for us, i.e. talk to the actual printers.  We 
currently support CUPS, LPD, LPR, LPRng, RLPR, and user/application selected 
program, but not Win or Mac.  Qt supports CUPS, LPD, application defined 
program, Win and Mac.  We also support switching systems in KPrintDialog, Qt 
does not.

Management Tools (aka kcm):  
These are things like KJobViewer, the kcm module, add printer wizard, etc that 
we use to configure/mangage the Printer Systems and Printers.  These are *nix 
desktop/platform specific tools and are not required on the other platforms 
where we don't provide the desktop.  Mac and Win provide their own equivalent 
management tools.

Basic/KDE3 Print Preview:  
Generates a ps file of the document which gets displayed, but is not
necessarily what the printer will generate.  Basically what you would
get if you printed the doc without any changes to the print settings.
The downside is if you do change print settings in KPrintDialog, such as
margins, 2-up, etc, these are not shown.  Must have for 4.0.

Server-side Print Preview: 
The printer sub-system (e.g. CUPS) generates the Print Preview for you,
so it is exactly how the printer will render it and fully reflects all
settings selected.  Not currently supported in KDE or Qt, but the ultimate 

(I'm not sure what Win/Mac does, nor which of these Qt 4.4. will support.)

Extended Print Dialog:
Ability to add an extra section/tab to KPrintDialog with application
specific printer settings.  Used in about a dozen apps, we cannot lose
this feature.  Qt 4.4 will support this on all platforms.

Special Printers
Ability to choose to 'print' to a destination other than a physical printer, 
e.g. PDF, PS File, Send Fax, E-Mail, etc.  These would not be available under 
a pure Qt solution (other than PDF).  Highly desirable to keep this ability 
in some form, if not from a print dialog.

Printing arbitrary page ranges/selections:  
The ability in the KPrintDialog to select to print only certain pages in a 
non-continuous range, e.g. 1, 4, 6-10.  This option is only available under 
CUPS and not under any other Printing Systems or Qt.  Nice to keep, but not 
fatal, can wait for 4.1.

Note, this is different to an application choosing what pages to submit to 
printing in the first place.

Pre/Post Filters:
Filter scripts that can be applied to the print job before or after rendering 
but before sending to the Print System (???).  KDE3 supports both, Qt unsure 
but almost certainly not pre-filters.  Used for things like pamphlets and 
posters.  Problem is most filters are ps based, so not cross-platform.  Would 
loose some nice features, but could work with trolls to regain.

Custom Margins:
Unique KDE feature to set custom margins for the print job.  This is not the 
document margins you find in KWord, but defining the print area on the page 
that the document will be painted into and scaled to fit.  (??? Not sure, I 
don't think anyone besides Kurt is 100% clear on this :-)

Driver Settings:
Physical printer output settings, e.g. colour/grayscale, duplex, etc.  
KDEprint provides a far superior GUI to adjust these, Qt is awkward to use 
but functional.

Other Settings:
Things like 2-up, banners, etc, are missing in QPrintDialog.

Comments on Issues:

KDE 4.1 / QT4.4:
We are making assumptions here that 4.1 will be out in say 6 months
(about the max tolerance of users for missing/broken features), and
QT4.4 before then, and that 4.1 will require 4.4.  Is this realistic?

CUPS Support: 
I haven't seen any info on exactly what CUPS version and features QPrinter 
supports, all I know is it supports CUPS and LPD.  I'm not even sure how much 
of CUPS that QPrinter needs to support, and how much is more kcm stuff.

If Qt already fully/mostly supports 1..1 & 1.2 and has committed to full
1.3/1.4 support in due course, then that makes things a no-brainer. KDEPrint 
has mostly complete 1.1 support, partial 1.2 support, and 1.3 is a 

Thomas, can you ask for us?

Management Tools to kdebase:  
While some parts of the Managment Tools are already in kdebase, these are just 
thin shells with most of the code in kdelibs.  With the policy of separation 
of a minimal cross-platform kdelibs and the *nix-oriented desktop in 
kdebase/workspace, kdebase/kdeprnt seems a better permanent home for all this 
code.  It just doesn't belong in kdelibs.

I strongly favour trying to move as much management code as possible, leaving 
only the bare essentials in kdelibs, i.e. print and preview and only the 
back-end engine classes required for this.  This keeps any possible redundant 
APIs to a minimum, shrinks kdelibs footprint, and minimises the chance of any 
accidental BC breakages later.

If there's still a lot of code left in kdelibs, I'd like to see it better 
organised into sub-folders, there's a lot of files in the base directory and 
it's confusing to work out what belongs to what (Namespace would help too).

Without an in-depth knowledge of the classes, doing this will probably
be a case of trial and error: move a lot of stuff, try compile, try
print...  I'm guessing that all the classes named km* are management so
that would be a start.

Print Preview:  
I've never been a fan of the Preview tickbox in the KPrintDialog, it's
just not obvious to the users, better is to have dialog buttons for
Print/Preview/Cancel, but showing users the KPrintDialog only works if
any settings they play with change the rendered preview, i.e.
server-side preview.  If the print preview does not respect the changed
dialog settings, then you might as well skip the dialog and just go
straight to the actual preview.  

I'd go with the redundant-in-4.1 API that simply displays a rendered file, so 
long as it's minimal, and that way we don't lose the menu entry which is also 
good for usability.

Given Qprinter natively outputs PDF now, just print that to a temp
file and call the default pdf viewer.  Would work under Mac/Win too,
even if throwing up Acrobat will take some time and look a little weird :-)  
The class wouldn't even have to be called KPrintPreview, it's really a 
generic KExportToPDF class.

Printing arbitrary page ranges/selections from KPrintDialog:  
I'm not sure I understand the difficulty here?  We don't do the actual page 
extraction anyway, CUPS does it for us, and it isn't available anywhere else.  
We pass the entire document to CUPS with the list of pages, CUPS does
the filtering for us and sends the result to the printer.  This seems ideal to 
be added to Qt 4.4's improved QPrintDialog.  We can survive 4.0 without it.

Special Printers:
Good argument for own KPrintDialog, but usability wise hiding these functions 
behind the File/Print menu item is something I've never liked.  A "File/Send 
To" menu item makes far more sense to me, with sub-menu options for PDF File, 
Fax Machine, Email, etc.

[Usability notes: I base these comments on observing my 65 year old father 
(social worker) and 30 year old sister (teacher) stuggling with the concepts 
when I converted them.]

Phew!  That's enough for now :-)


Send instant messages to your online friends http://au.messenger.yahoo.com 

More information about the kde-core-devel mailing list