Bug 190646

I miss the print odd/even pages option, too..

But you're talking about manual duplex printing, right?
You might wanna vote for this feature then:
https://bugs.kde.org/show_bug.cgi?id=60037

yes, i'm talking about manual duplex printing. anyway, that wish is difficult to implement, and it could necessary to wait some time... i'm speaking aobut a simple feature that allow to print (for istance) first odd pages, then you manually rotate the pages and print even ones. is it possibile to implement it?

It's not difficult to implement a manual duplex printing option.

First of all, it's possible to check if the printer can do duplex prints or not. If it can't do this, then you should have the option to for manual duplex printing.

This could be very easily be done with an additional dialog. You check "manual duplex printing", then click the "print" button. The program itself will now print first the odd pages, then ask you to put the printed pages back into the printer and to click the "ok" button. Then it will print the even pages, but in reverse order.

Now we have the problem here that not all printers work the same way. On some you might have to change this sequenze. Therefore there has to be an initial configuration. The first time you do manual duplex printing, you've got to configure it. The easiest way is just selecting the order and do a test print. You need at least 2 pages for the test. It should be enough to print the numbers from 1 to 4 on those pages. After the test print, the numbers should be in the right order. On the first page the 1 and on its back the 2. And on the second page the 3 and on the back the 4.
If not, you've got to change the order. It should be easy to find out which order is necessary, just by the way the numbers are printed. It could be a wrong order (the 3 is on the first page, the 1 on the second, then you have to print the even pages first) or the number is upside-down, then you've got to rotate the page (either when printing or with a ps hook).

Hopefully my description is good enough to get the idea behind it.

*** This bug has been confirmed by popular vote. ***

In reply to #3.

I do not agree that the manual duplex support is easy to implement at all. Not that it would not be a desirable feature and I would like to have it, but in case it is done, I would like to see it done properly:

1) Where do you put the information about how the printer works? In a kde database? How ugly. Would it be tied to the printer "name" or the printer model? If it is tied to the printer name, by changing the printer name I would lose this information. Please consider that there are users who are "roaming" (e.g. because of laptops that should be used in the office, at home, etc.) and use profiles and scripts to update the cups printer configuration depending on the location. The manual duplex should not mess out things that are working now.
Also, it would be very inelegant to scatter printer information in many different places (a bit in a kde database, a bit in the cups one).
IMHO it should be cups (who knows about the printer model) also to know about the way in which the printer prints (e.g. from the printer ppd description) and that should be able to report it to kde or whatever desktop environment one uses. So before implementing something in the wrong way, it would be better to speak to the cups people.

2) To do manual duplex one needs a printer queue locking mechanism. Unix and thus linux is by nature a multiuser and networked OS. There can be other people using the printer. So, requests should be sorted so that it is impossible that someone else work gets printed on the back of my work.  Again support is needed from the cups people.

So please, until all this is sorted, support the odd-even page selection that is a trivial feature, that was perfectly working in KDE 3 and that after 3 KDE 4 releases is still not there.

Please, can someone fix this? I always print in this way to save paper. It's so annoying, i have to keep evince around just for printing.

> Please, can someone fix this? I always print in this way to save paper. It's so annoying, i have to keep evince around just for printing.

Why evince? Does it not work to keep good old KPDF 0.5.10 around for printing?

I agree with Sergio.
Manual duplex is not an easy thing to do on a multi-user system such as Linux, not without involving CUPS too.
Printing even/odd pages is much easier to do from the KDE-perspective.

Manual duplex is a thing that should be implemented by CUPS and only then enabled in KDE; printing even/odd pages is a thing that can be done directly by KDE so i would suggest to get this working first.

(In reply to comment #7)
> > Please, can someone fix this? I always print in this way to save paper. It's so annoying, i have to keep evince around just for printing.
> 
> Why evince? Does it not work to keep good old KPDF 0.5.10 around for printing?

kpdf doesn't exist any more in current distros, evince does. It's just annoying that such regressions is comparison to KDE 3 still exist. I mean, KDE 4 is called stable now for how long?

(In reply to comment #9)
> (In reply to comment #7)
> > > Please, can someone fix this? I always print in this way to save paper. It's so annoying, i have to keep evince around just for printing.
> > 
> > Why evince? Does it not work to keep good old KPDF 0.5.10 around for printing?
> 
> kpdf doesn't exist any more in current distros, evince does. It's just annoying that such regressions is comparison to KDE 3 still exist. I mean, KDE 4 is called stable now for how long?

I use Gentoo and am thankful that they still have the usable version of KDE around. Hopefully they will keep it around until this regression is fixed (or I buy a duplex printer). But the maintainers are of course frustrated that it is abandoned upstream. So maybe I will have to use evince too for printing some day. Maybe it is not so bad after all.

kpdf is not abandoned upstream just gained lots of features and morphed to okular

> kpdf is not abandoned upstream just gained lots of features and morphed to okular

kpdf, the program that can print only odd/even pages, is abandoned. Okular is not a replacement, because it can not do that.

I'm sorry but that's simply not true, maybe it's what you see from your user point of view, but from the programmers point of view, okular does more things than kpdf did, it's just that the KDE3/Qt3 framework was better than the KDE4/Qt4 regarding printing, you can't blame okular for that. Well you can if you want, but it's not its fault.

Can you please stop fighting in this bug report? KDE is using the Qt printer dialog, and it makes sense to use it and implement this feature there and not creating our own dialog.

Means: Please request this feature here:
http://qt.nokia.com/developer/task-tracker

That's not true. Just because Qt Software did not implement a feature in QPrinter does not mean that someone from KDE could not create a new "KPrinter" class that inherits from it.

The problem is not that Qt does not have the feature - it's that there's no one who wants to do it.

Well, if noone wants to improve QPrinterDialog why is there someone who wants to write our own KPrinter class, instead of just improving QPrinterDialog? This looks like a logical error to me...

http://www.layt.net/john/blog/odysseus/we_have_code

Please, stop fighting in this bug report.

That's good news! Hopefully it will get accepted.

Am I right to say (if not please correct me) that:

1) In Nokia's bug traker for QT the feature request is at http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318

2) such feature request is accompanied by very little supporting material. Specifically, there is no link to this bug report, nor any indication that the lack of odd/even page selection brings as a consequence one of the most criticized KDE regression from 3 to 4.

3) possibly as a consequence, only a very low priority has been given to the feature request

4) the feature is not (not yet) in the planned feature list for qt 4.6, meaning that we might have to do without it for another year or more if it does not get accepted.

5) among the feature requests on Nokia's site there is no mention at all of other printing features that kde 3 had, that acrobat reader has and that the QT printer dialog misses, such as
- smart page selections (e.g. "4,5,7-10")
- page reordering for booklet printing

6) in principle if the new code mentioned above is accepted, there is a chance to do the page selection much better than it was in kde 3. There, the application had to render all the pages, and the page selection was done afterwords. Here the application can be aware of the page selection and only render those pages that need to (e.g. think of printing only page 1 from a 2000 page PDF).

7) It would be nice and possible to get features that were not even available in kde 3. I am specifically thinking of distinguishing odd/even (namely page selection made on source page numbers) from front/back (namely odd/even page selection made with reference to what actually goes on paper. For instance, imagine the case where one has a document were he is interested only in pages 1,7,8,9 and 11 and he wants to select them and printer them with manual duplex. He would need first to do the page selection on the source pages, and then the front/back selection with regards to what goes on print. Or think of a document where all even pages are "intentionally left blank for notes". It would be nice to first select odd pages only and then to still be able to select the front pages and the back pages for manual duplex.

8) There appears to be a strong request for "software supported manual duplex". However, it would be weird to have this request considered as alternative (mutually exclusive) to even/odd page selection. Furthermore it would be strange to see this request delaying the simpler odd/even selection mechanism.
So it makes little sense to ask for "software supported manual duplex" /instead/ of even/odd page selection.

9) "Software supported manual duplex" would need some help from the print system (typically cups) side. For instance, locking the printer throughout the operation is necessary since linux is a multiuser OS (something that the typical desktop user may easily forget). Also, the printer description in the print system database should contain information about how the manual duplex is to be done (since such information belongs there and not in the desktop environment). So it would be nice to first have the cups camp accept the idea of supporting manual duplex, and only then think of introducing it in kde.

I am mentioning the above points since it helps me better understand how to most proficiently support the enhancing of the printing features of kde 4.

My current feeling is that there have been many complaints about the lack of features in kde 4 with regards to kde 3, to the point of making some developers unhappy. Indeed, developers have a point in saying that the users should realize that features depending on other software projects (such as QT in this case) cannot be instantaneously implemented by KDE developers only.

On the other hand, it is understandable that most users see just "KDE" and not the pieces it depends upon and so they write/complain to KDE lists and not elsewhere. To me, the real problem is that there is no thorough passing of the feature requests from the KDE bug reporting system to the upstream projects task trackers, with the unfortunate result that upstream no one really can appreciate how important some features are considered by KDE's users.

Is there some way to fix this?
- Should we start linking this bug into http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318? Would it be better to crosspost?
- Should we start requesting some support for "assisted manual duplex" in cups now?

(In reply to comment #19)
> Am I right to say (if not please correct me) that:
> 
> 1) In Nokia's bug traker for QT the feature request is at
> http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318

Right.

 
> 2) such feature request is accompanied by very little supporting material.
> Specifically, there is no link to this bug report, nor any indication that
> the lack of odd/even page selection brings as a consequence one of the most
> criticized KDE regression from 3 to 4.

Right.
 

> 8) There appears to be a strong request for "software supported manual
> duplex". However, it would be weird to have this request considered as
> alternative (mutually exclusive) to even/odd page selection. Furthermore it
> would be strange to see this request delaying the simpler odd/even selection
> mechanism. So it makes little sense to ask for "software supported manual
> duplex" /instead/ of even/odd page selection.

Right. Please forget about fancy features like "software supported manual duplex" for now and focus on feature parity with KDE3. Do not delay it further because there are ideas about making something even better.


> 9) "Software supported manual duplex" would need some help from the print
> system (typically cups) side. For instance, locking the printer throughout
> the operation is necessary since linux is a multiuser OS (something that the
> typical desktop user may easily forget). Also, the printer description in the
> print system database should contain information about how the manual duplex
> is to be done (since such information belongs there and not in the desktop
> environment). So it would be nice to first have the cups camp accept the idea
> of supporting manual duplex, and only then think of introducing it in kde.

Right.


> - Should we start linking this bug into
> http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318?

By the way, I can not even figure out how to subscribe to that issue.


> - Should we start requesting some support for "assisted manual duplex" in
> cups now?

Sure, but as you concluded, getting the basic page selection features back in KDE is far more important.

*** Bug 214558 has been marked as a duplicate of this bug. ***

The feature request at http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318 has been closed with "Resolution: expired".
Now what?
Open another one and continue waiting for Nokia to fix it?

(In reply to comment #22)
> The feature request at
> http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=219318
> has been closed with "Resolution: expired".
> Now what?
> Open another one and continue waiting for Nokia to fix it?

It looks like that has already been done. The expired bug report has the link to a new bug report with Status: Open.

Here is a direct link to the new bug report:
http://bugreports.qt.nokia.com/browse/QTBUG-2444

Closing as Qt/Upstream