Printing/Missing Features

From KDE Community Wiki
Revision as of 21:23, 27 May 2011 by Jlayt (talk | contribs) (Created page with ' Motes on missing features from original QPrinter decision process, revise in light of current situation. == Definitions == First, a definition of some terms and features as I ...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Motes on missing features from original QPrinter decision process, revise in light of current situation.

Definitions

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

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

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

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

Functional Split

KDEPrint currently provides the following 3 primary functions: 1) Creation and submission of print jobs by applications 2) Management of print jobs/queues 3) Management of printers and print systems

Only 1) is required across all platforms and must be provided in KDE4.0 in kdelibs. Both 2) and 3) are only required on *nix systems, Win and Mac provide their own facilities. These should live in kdebase.

We are seeking a solution to 1) short-term for KDE4.0 and long-term for 4.1. Both 2) and 3) can be managed for 4.0 in a slightly broken state, with full support restored in 4.1, as BC and API guarantees do not apply.

Potential 4.0 Solutions

Pure Qt: Gain win & mac support, remove maintenance burden, loose many features until added to Qt Inherit Qt: Gain win & mac support, minimise maintenance burden, keep many features Keep KDE: No win & mac support (?), heavy maintenance burden, keep all features

Printer Systems

Systems that manage the printers and print queues for us. CUPS is the most common on *nix, providing many features directly and keeping the drivers to a minimum, uses postscript as internal format. Mac uses its own, partially non-compatible (?) version of CUPS. Win provides a more basic infrastructure that relies on the manufacturer written drivers to provide many features, uses an internal binary format .

KDE3: Supports CUPS, LPD, LPR, LPRng, RLPR, and user or application selected program. Ability to switch system in Printer Dialog.

QT4.3: Qt supports CUPS, LPD, application defined program, Win and Mac.

QT4.4:  ???

KDE4.0: Need CUPS, LPD, application defined program, would like Win, Mac

KDE4.1: Support CUPS, LPD, application & user defined program, Win, Mac

Bottom line: Qt solution would give us Win and Mac for free, but loose lesser *nix systems, ability to switch systems on the fly, and user selected programs

CUPS Support

CUPS has multiple spec versions, 1.1 and 1.2 are most widely used versions, 1.3 recently released, 1.4 currently in alpha. Largely (?) backwards compatible, each version adding more features. Features are split between printing and admin functionality. Some features compulsory to make printing work, others are optional to enhance user experience.

KDE3: Minimum version 1.1.20. 1.1 support mostly complete. 1.2 support partial. 1.3 support non-existant.

QT4.3:  ???

QT4.4:  ???

KDE4.0: Minimum version 1.1.20, unable to look at extending support.

KDE4.1: Aim for complete 1.2 support in management tools?

Bottom line: Qt solution uncertain for printing support, but management support is in our own hands

Print Preview

Basic Print Preview: Render document to file and display, this is not necessarily what the printer will generate and it does not reflect settings changed in the Print Dialog, such as margins, 2-up, etc. Basically what you would get if you printed the doc without any changes to the print settings.

Server-side Print Preview: The Printer System (e.g. CUPS) renders the Print Preview for you, so it is exactly how the printer will render it and fully reflects all settings selected in the Print Dialog.

KDE3: Basic Print Preview

Qt4.3: No print preview support, could fake Basic Print Preview by printing to PDF and calling default viewer.

Qt4.4: Proposed cross-platform Print Preview facility, not sure if Basic or Server.

KDE4.0: Require Basic Print Preview

KDE4.1: Server Print Preview desirable

Bottom line: Qt4.4 promises

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.

KDE3:

Qt4.3:

Qt4.4:

KDE4.0:

KDE4.1:

Bottom line:

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.

KDE3:

Qt4.3:

Qt4.4:

KDE4.0:

KDE4.1:

Bottom line:

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.


Print Ranges

Application selected: Application chooses what pages to submit to Print System/Print Dialog User selected continuous User selected non-continuous

Bottom line:


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.

Bottom line:

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.

Pre-filters: Applied to the print file (ps/text/whatever) received from the application before being passed to the Print System (???)

Filters configured via xml file, has gui.

Available pre-filters ?

enscript – Enscript Text Filter (with pretty code printing) (bin = enscript) - html/plain/sgml/x-c++hdr/x-c++src/x-chdr/x-csrc/x-java/x-makefile/x-pascal/x-python/x-tcl/x-tex/xml/x-fortran/x-perl/x-perl-module/x-python/docbook+xml/x-log/x-patch/x-ruby to ps imagetops - Generic Image to PS Filter (bin = imagetops) - jpeg/png/x-png/bmp/gif/tiff to ps pdfwrite - PDF Writer (bin = gs) – ps to pdf poster - Poster Printing (bin = poster)- ps to ps ps2pdf - PostScript to PDF Converter (bin = gs) – ps to ps psbook* - Pamphlet Printing (bin = psbook) – ps to ps psnup – Multiple Pages per Sheet (bin = psnup) – ps to ps psresize - Scale Print Content to Fit on Another Paper Size (bin = psresize) – ps to ps psselect - Page Selection/Ordering Filter (bin = psselect) – ps to ps


Bottom line:

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 :-)

Bottom line:

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.

Bottom line:

Other Settings

Things like 2-up, banners, etc, are missing in QPrintDialog. These are special GUI’s for filter options.

Management Tools to kdebase

While some parts of the Managment Tools are already in kdebase, these are just thin wrappers 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.