I promised an update on printing and here it is.
Just to recap, the branch at http://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/advanced-page-selection contains the Advanced Page Selection features such as Current Page, Odd/Even Pages, Server Side page selection, and non-continuous Page Ranges. The status of this is that it's API complete with just some polishing work required in the Unix dialog, although there are a couple of implementation details I'm reconsidering as being too ugly.
My next step was to add in support for file printing which you can find at http://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/print-from-file. This is useful for applications such as Okular where they have a high quality source file and don't want to paint it onto a QPainter (and possibly reduce the quality in the process) before printing it. This is a simple API where the application passes in the name of the source file to be printed, and if the filetype is supported by the print system the file gets printed using the settings from the QPrinter (and thus anything the user selected in QPrintDialog). Under CUPS you can print PDF, PS, TXT and various image formats while lpr will support just PS and TXT. It's still a little hacky in places, such as the filetype detection, but it works. And for the more observant of you, yes this will make a new kprinter utility a lot easier for someone to implement.
I've also made a start on adding all the available CUPS options into the Unix QPrintDialog. At the moment KDE adds these as extra aplication-level tabs on the dialog, but they are poorly integrated, e.g. choosing 'Print to File' doesn't disable them. The code for this is still very rough and so still rather ugly, but I've attached screenies below showing some options in a new Pages tab in the main dialog, with others in a new Job tab in the Properties dialog. Yes it looks just like the current KDE stuff as I've recycled the code I wrote for that. I must confess the more I try to mess with the QPrintDialog, the more tempted I am to re-write it from scratch, it shows obvious signs of cruft building up over years of having bits bolted on by several different people.
Last time I mentioned that the Qt 4.6 feature freeze was looming. Well in fact it had already long gone whizzing past with no-one much noticing, so sorry but these changes won't be in Qt 4.6 or KDE 4.4. This whole open Qt development thing is very new and the processes aren't really in place for contributing features (as opposed to bug-fixes) and I guess there's a few lessons to be learnt along the way. I should have been more pro-active in talking to the Trolls about the how and when, so lesson one is if you have a new feature grab your nearest passing troll and don't let go until they let you cross the bridge to graze in the summer pasture, er I mean until your stuff gets merged. From the Qt side I guess there needs to be more structure and documentation around the steps developers need to follow to propose, design and develop new features, who do you talk to first, what are the release schedules and milestones you need to meet, and what you need to include (unit tests, cross-platform support, documentation, etc).
It has been suggested that my patches could be packaged into Qt4.6 by some distros, but this is not going to be possible as I cannot guarantee that the API/ABI will remain unchaged through the Qt review process, or even that they will be merged for Qt 4.7.
However all is not lost as I have been able to re-use some of what I've done to add Odd/Even pages and Server Side page selection for KDE 4.4 using CUPS. Using a very very ugly hack, I've added the Odd/Even selection combo into the QPrintDialog and this gets passed through to CUPS if selected. A less ugly hack has also added Server Side page selection where CUPS will select the page range when the application can't, i.e. Kate and Khtml and all apps that embed them (KMail, Konqi, KWrite, etc) can now print page ranges! The main drawback is this only works under CUPS, and it doesn't intergate well, i.e. the Odd/Even combo doesn't disable when you choose 'Print to File' so we'll get plenty of bug reports that it doesn't work with 'Print to PDF'. However I think the users need for this outways the shortcomings. Also be warned that using them in conjunction with n-up will get unexpected results due to a quirk in CUPS where it applies the page selection to the sheets of paper and not the document pages. Screenie below showing KWrite with Odd/Even selection added and Page Ranges restored.
As an aside, I've been thinking about how to make kate and khtml support page ranges properly. At the moment they just paint the whole document as they don't know where the page breaks will be until after they have actually painted the content onto each page. Trying to calculate this in advance and to pick up the painting mid-stroke is I believe a very tricky proposition. Instead, I was thinking we could have two identical QPrinter's, a dummy QPrinter onto which the first few unwanted pages are painted, then once the first required page is reached a second 'real' QPrinter onto which only the required pages are painted. Not sure if it's feasible, but worth a crack?
Of course, the obvious perfect cross-platform solution would be if QPrinter itself directly supported page selection, i.e. you paint all the pages onto QPrinter then tell it which ones to keep and it deletes the rest internally before passing the document to the native print system. Something else to look into.
[Edit: fixed references to QPainter to be QPrinter]
So, where to from here? There's obviously going to be a bit of time now before these possibly make it into Qt 4.7 (whenever that may be), so I'm going to re-arrange my priorities. We have the KDE 4.4 feature freeze coming up next month, so I'm going to focus for a bit on doing some Calendar and Locale related hacking for that. Then for the Qt 4.6 release I need to work on some bug fixes for the current printing code. After that, and depending on when 4.7 is rumoured to be released, I'll get back onto finishing off all the above and also trying to sort out the situation with saving settings between jobs. And in-between all that, I need to get back in touch with the OpenPrinting guys to work out how KDE can help them in their quest to completely re-architect the way we do printing.