[Kde-print-devel] Future of KPrinter

[Kurt Pfeifle]

(Disclaimer: it may well be that I completely misunderstand your techni-
cal considerations, or rather: their low-level Qt/C++ part, and therefore
it may well be that I'm totally off with my comments...)


Alex Merry wrote:
> Thomas Zander suggested we kill off KPrinter in favour of QPrinter 
> (http://lists.kde.org/?l=kde-core-devel&m=118918127627566&w=2).

*shudder*

> Here's a list of the features provided by the KDE printing system that 
> the Qt printing system doesn't provide:
>
> * Customisable print dialogs - would require implementing our own 
> KPrintDialog
> * Straightforward printer options (try clicking "properties" for a 
> printer in the print dialog of the Qt assistant program, and doing the 
> same in kolourpaint), ie: integration with KDE print management system - 
> would require implementing our own KPrintDialog
> * Printing a list of pages (such as 1,4,6-8) or the current page - would 
> required extending QPrinter and implementing our own KPrintDialog, or 
> we could just tell people to get this info from KPrintDialog (it's only 
> needed by the application, not by the printing system)
> * Custom margins - would require extending QPrinter and implementing our 
> own backends (which might use a Qt builtin backend)
> * Pre-print filtering - would require extending QPrinter and 
> implementing our own backends (which might use a Qt builtin backend)
> * "Special" printers (like Send Fax via KFax) independent of eg: CUPS - 
> would require extending QPrinter and implementing our own backends 
> (which might use a Qt builtin backend when not printing to the special 
> printers)
> * Print preview - more complicated.  We could probably provide a 
> KPrintPreview class that uses a QPrinter to print to a file and then 
> display that:

I suspect your list is way too short, because it takes into account only
one side of KDEPrint's interaction.

KDEPrint is in the middle between applications and print subsystem (for
99.9% of users that would be CUPS now). You enumerate only the stuff
that is dealing with the application side.

Also, in part at least, you don't seem to be familiar with CUPS and cur-
rent KDEPrint. (For example, the "list of pages" you mention: this list
is handed to CUPS as a parameter, alongside the all-pages containing
print job. And it is then CUPS with its pstops filter that extracts the
pages named for printing. (And I'm not aware if any KDE application does
use this to *itself* do the page selection for the print job).

But KDEPrint now is (or was, in CUPS 1.1.x times) really good also in
dealing
with CUPS. It is fully IPP aware: can talk to a remote CUPS server (not
sure if Qt Assistant's print dialog can do that), and very flexible in
switching to a different CUPS server (nearly on the fly) when moving into
a different department (in cases were CUPS browsing is not enabled, or
when a thin client does not have a local cupsd running).

If you want to get a glimpse, look at all the "WhatsThis?" help hints in
kprinter. (Last time I looked they were not present in KDE4's kprinter
-- not sure if they all were scrapped during the port, or just disabled.
So, to see them, use kprinter from KDE3).

They'll show you also in most cases which CUPS commandline print option
a specific GUI control in kprinter maps to.

The "Properties" button in the Qt assistant's print dialog displays the
same thing that the "Drivers" tab in kprinter provides: it reads the
PPD from CUPS and displays the user-selectable options.

The "General", "Text", "Images" and "HP/GL2" tabs are there because they
provide support for features that are in CUPS.

Most the content from the "expandable" part of the frontup kprinter dialog
(Copies, Advanced Options, Additional Tags) is there, because it provides
support for features that are in CUPS.

Most the content from what comes up behind the "System Options" button is
there, because support for CUPS...

In fact, if you look closely at it, kprinter doesn't talk much at all with
the application. It just gets the job (in the form of a PS file). It talks
*way* more with CUPS.

So the discussion seems, for me, seems to go in "gain me a bit better
support from Qt in order to talk to the applications -- the other side to-
wards the print system we don't care much for now (we don't understand it
anyway)".

If you throw out KDEPrint's current capabilities in favor of Qt Assistant-
like printing, KDE4 is toast in server-based computing environments, as
compared to KDE3, and not only there....

> Are custom margins really needed?

I use them every time I print webpages (Konqueror) or text files (kate).
Yes they are needed.

(But as always, it always depends whom you ask.  Ask *me* if *I* need
sophisticated audio/video/multimedia support in KDE4 and I'd say "no".
But that doesn't mean I'll suggest removing it.)


-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany