- 1 EMail to Pino/Thiago
- 2 One draft
- 2.1 Definitions
- 2.2 Functional Split
- 2.3 Potential 4.0 Solutions
- 2.4 Printer Systems
- 2.5 CUPS Support
- 2.6 Print Preview
- 2.7 Management Tools (aka kcm)
- 2.8 Extended Print Dialog
- 2.9 Special Printers
- 2.10 Print Ranges
- 2.11 Printing arbitrary page ranges/selections
- 2.12 Pre/Post Filters
- 2.13 Custom Margins
- 2.14 Driver Settings
- 2.15 Other Settings
- 2.16 Management Tools to kdebase
- 2.17 Print Preview
- 2.18 Printing arbitrary page ranges/selections from KPrintDialog
- 2.19 Special Printers
EMail to Pino/Thiago
Standard Cross-platform features:
- Current Page (3)
Select Print Range to print current page only. Merge requested.
- Multiple Page Ranges (2)
Entry of multiple page ranges to print, e,g, "1-3,5,9". Merge request almost ready.
- Page Set (Odd/Even) (2)
Select to print All, Odd or Even pages. Merge request almost ready.
- Print From File (1)
Accept a print file from the app to submit to the print system. Mac and X11 have API to support this, Windows seems unlikely. I have some code.
- Save/Load Settings (1)
Allow apps and/or users to save and restore current print settings. Would need syncing with Mac settings system, X11 and Windows have none. Add user interface to X11 and Windows print dialog in same style as Mac.
- Application Tabs (2)
Apps can add own tabs to dialog, currently X11 only. Add Windows and Mac support, both have native API to do so. Will need to integrate with save/restore settings.
- Reverse Page Order (4)
Choose to print last page first, currently X11 only. Add Windows support, and possibly set-only Mac support.
These really are the minimum must-have features.
[Page Set, App Tabs, User Settings and Reverse Order on Windows need the same piece of code to customise the standard windows dialog, which I need help on]
- CUPS Server-side Page Selection (2)
CUPS selects pages to print if app cannot (KatePart, KHtml need it) I have code.
- CUPS Job Scheduling (4)
CUPS job options like print time, priority, banner pages, billing info. Own tab in Properties dialog? I have code.
- CUPS Page Handling (4)
CUPS page options like n-up, border, label, mirror Own tab in main dialog? I have code.
- Improved PPD widget in properties dialog (4)
Current widget has bad usability
We have add-ons for most of this in KDE so are lower priority, but should be quicker to implement as we already have code to work from. It's just a matter of deciding which features are supported and where in the dialog they go. note this is all internal to the X11 dialog, no QPrinter changes required.
Advanced document formatting:
- N-up (cross-platform, not CUPS)
Printing several document pages on each sheet of paper
Printing a document page across several sheets of paper
- Manual Duplex
Help user to manually print a duplex document using a simplex printer. May be better as a wizard, but could be built into the dialog.
Basically taking a rendered document and manipulating where on the sheet of paper each document page will appear. Someone to talk to will be Thomas Zander who has some ideas about implementing these in a cross-platform way using QPrintPreview (but I'm not sure that will work for Print From File).
Blue-sky stuff that needs a lot more thinking about:
- Special/Virtual Printers (Fax/Email/etc)
Ability to choose to Print to Email or Fax or wherever from the printer selection combo. Could link to QPrinter::setPrintProgram() somehow? Or modified versions of print dialog where the Printer section at the top is replaced with a Email / Fax / Whatever specific section? May be better as 'Export to' menu options.
- Pre/Post Filters
Run the print file through user defined scripts, maybe using QtScript? In KDE3 mostly used for n-up, booklet, poster, etc, so not a high priority if those supported natively.
- Print Preview button in Print Dialog
Add a 'Preview' button next to 'Print' and 'Cancel' that applies any selected print options and then launches QPrintPreview
- Small Preview in Print Dialog
- OpenPrinting dialog
These 3 are the 'pull-printing' concept as implemented by OpenOffice and OpenPrinting where either the app first renders the entire document and then hands it off to the print dialog to manipulate as requested and submit direct to the print system, or for long documents renders the first page and the dialog requests any more required pages from the application. Central to this is a preview embedded in the dialog that shows the real result of the dialog options. OpenOffice has this entirely internal, but OpenPrinting are implementing it over DBus calls that Qt could integrate with.
Notes on missing features from original QPrinter decision process, revise in light of current situation.
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.
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
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.
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 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.
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
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.
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.
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.
Application selected: Application chooses what pages to submit to Print System/Print Dialog User selected continuous User selected non-continuous
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.
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
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 :-)
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.
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.
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.
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.