Version: (using KDE KDE 3.2.1) Installed from: SuSE RPMs OS: Linux When having a printer configured to print multiple pages per sheet (2 in my case), and then selecting to print only the odd pages, The pages get printed in the following order: 1st sheet: page 1 and 3 2nd sheet: page 5 and 7 3rd sheet: page 9 and 11 etc. While this seems to be correct behaviour, it's actually rather stupid. The only common reason to only print odd pages is to be able to print the flip sides with the even pages of the same document, just manually printing two sides of the paper. With the current setting, I'd get these results: 1st sheet: page 1 and 3; flip side: page 2 and 4 2nd sheet: page 5 and 7; flip side: page 6 and 8 3rd sheet: page 9 and 11; flip side: page 10 and 12 While I'd rather see: 1st sheet: page 1 and 2; flip side: page 3 and 4 2nd sheet: page 5 and 6; flip side: page 7 and 8 3rd sheet: page 9 and 10; flip side: page 11 and 12. which is just how I expected it to come out in the first place. My point is that the odd/even page printer should print the odd pages *after* the document's gone through the multiple-page-per-sheet-generator (or however that works;) ), rather than first selecting the pages to be printed, and *then* fitting them on a sheet. I hope my explanation of the problem is clear enough..
Er, this is a bug, not a wishlist item..
Ditto this bug for me. Debian Sid, KDE 3.4, and it still does that. I have to run my stuff though pdfnup or the like manually before I can print them odd/even-wise. This behaviour is actually very counter-intuitive. Technically correct, but utterly useless. Can we get a fix?
*** This bug has been confirmed by popular vote. ***
Still there in kde 3.5. Very annoying. Requires specifing each page number manually.
i have 3 different behaviors with my KPrinter(0.0.1): 1. if i print with range set "all pages" and only odd pages, everything works like i want (1st sheet: page 1 and 2; flip side: page 3 and 4 ...) 2. if i print range "1-24" e.g., the result is like 1st sheet: page 1 and 3; flip side: page 2 and 4 3. if i set the range to "1,2,5,6,9,10,13,14 ..." it prints 1st sheet: page 1 and 5; flip side: page 2 and 6 i think all three results should be the same (perhaps there should be a "print every second page"-option to make the 3. behavior more clear)
i guess there is something more, because when i try to redo it like number 1. the result is now like number 2. i think it must be the reason that, when i printed it the first time, it was a couple of different files in one turn ("kprinter file1.pdf file2.pdf file3.pdf...") and the pages i was talking about are a set from a file in the middle of this couple (file3.pdf).
oh, seems like kpdf changes the way of printing here! with kpdf i get "1st sheet: page 1 and 3; flip side: page 2 and 4 " and with pure "kprinter file.pdf" i get "1st sheet: page 1 and 2; flip side: page 3 and 4 " (both times with "all pages"/odd pages/->flip/even pages) sorry for trippleposting ...
Duplicate of bug 107936. Please read comments on the thread over there as well. And transfer your bug votes, if you care. *** This bug has been marked as a duplicate of 107936 ***
I would say that this bug was first and 107936 should be duplicate of this one. See the numbers. Transfering votes anyway.
Arkadiusz, ...and it had more votes. Well, sometimes you have to make a decision. And it's not always "fair". But formalism like ("the oldes should prevail") would be stupid. Sometimes the newer one has more discussion, better arguments, a more precise headline etc. I intend to only get work done and bugs solved, not preferring one bug reporter over the other :-)
Please continue discussion of this bug at bug 107936
Sander, Brandon, what you want is just impossible right now with the *automatic* stuff KDEPrint is able to do.... KDEPrint *itself* doesn't do anything to the printfile (and the documentation does make that pretty clear) -- it merely runs external tools, and combines them together. And sometimes the results are unexpected (bug of the external tool? - bug in KDEPrint not passing the correct parameters to external tool? - bug in the PostScript file itself? - bug in the user's perception who may not be fully aware ho0w the tools are supposed to function?)... Anyway... let me make a proposal for printing your stuff, and getting an outcome as you describe in your initial report: * Don't set anything in the main print dialog! Leave "All" pages, and "All" pageset, don't select any number-up there. * In the "Properties" part of the print dialog set up a chain of "pre- filters". * That is: locate the "Filters" tab * On the Filters tab enable two filters (in that order!): as the first, use the "Multiple Pages per Sheet" filter; as the second, the "Page Selection/Ordering" filter * Make sure the two pre-filters are set up correctly: multiple pages set to "2", the page set to "odd". * I hope you can discover by your own how to set these things (hint: there is an icon with a wrench, and its tooltip says "Configure filter". * After you've printed the front pages of the sheet, now repeat the same prodedure with the back pages. (You may want to use one of the "Reverse" switches for reverse order of printout in order to avoid the manual sorting of your in first pass printed sheets). So what would you say, is the reason for this bug report? - A bug in one of the external tools KDEPrint uses? - A bug in KDEPrint not passing the correct parameters to the external tool? - A bug in the PostScript file itself? - A bug in the user's imagination or inability to read tooltips+WhatsThis and to discover the tools that are there right underneath his nose? You are welcome to report more bugs regarding KDEPrint. But please, before you do so, take the time to look through the dialog when activating the little "WhatsThis" questionmark cursor, and click on the different controls to learn what they do and how they are supposed to work. Cheers, Kurt
Created attachment 19277 [details] How to set up kprinter to achieve what the supposed bug supposedly prevents the reporter to do
Created attachment 19279 [details] Proof (by print preview with kpdf) that kprinter achieves what the reporter wants to do
Very cool, that is indeed what this bug was about. So in answer to your question, I'd say this is indeed "A bug in the user's imagination or inability to read tooltips+WhatsThis and to discover the tools that are there right underneath his nose" However, as could be seen by the many votes on this bug, the behavior kprinter currently displays is experienced as counterintuitive by many people. You could say these people all should descend into the deepest regions of kprinter and find out on their own how to achieve this, however not everybody has the same knowledge and willingness to understand kprinter's underlying functionality when all they want to do is print a document double sided with a printer that can handle only single-side printing. Since I believe the group of people who possess only such a printer is quite large, maybe the procedure should be made more intuitive/easy to perform. You already explained the algorithm for doing this, so what would be the problem with putting all this functionality in just one button or checkbox or something to make the functionality more obvious? Doing this would reduce this bug to a UI bug in kprinter, which would still be very relevant. I say we reopen this bug as such.
Sander, I'm glad I could help you. :-) "You could say these people all should descend into the deepest regions of kprinter and find out on their own how to achieve this" Yes, that's what I'm saying... :-) .... but only to *those* people who hit me over the head with rebukes like "But I had to run stuff through pdfnup or the like manually" (because *these* people do proof that they can run advanced tools on the commandline just fine, so it is not their business to attack other people who work in their spare time to make these very tools (which are very dis-parate and behave very differently on their own) better accessible via a single GUI. I'm usually quite patient, and I explain stuff that I know to other people who want to listen. But my time is very limited (and the stuff that I know even more so). "...when all they want to do is print a document double sided with a printer that can handle only single-side printing. -- Since I believe the group of people who possess only such a printer is quite large, maybe the procedure should be made more intuitive/easy to perform." I invite you to create a detailed and concrete proposal how to implement this. No, I don't mean to write the C++/Qt code (you probably can't code, like I myself can't; if you can, please offer your help). I mean create some gimp-ed mockups, some drawings, some rough visual representations of how it should look like in your opinion. Do some "paper prototyping". But take into account the *overall needs* of KDEPrint which must cater for a lot of different apps: KDE's own ones *as* *well* *as* *external* *applications*. How should the overall layout of the printing dialog be looking: Where to place which buttons? Where to position other widgets? How does the workflow for the user look like? What is differnt if she whats to preview first? What is different if she prints from a browser? From a KOffice application? From kpdf? What if he has access to 20 different printers (big office)? What is different for home users from corporate users? What is different for big TCP-connected laserprinters from small color inkjets connected via USB? Don't forget installation/setup tasks, don't forget job control wishes, don't forget security... I'm sure that for a good design and layout of the dialogs we will also find people who'll write the code to implement it. I'm not sure you'll even sit down for an hour and think about it... "I believe the group of people who possess only such a printer is quite large, maybe the procedure should be made more intuitive/easy to perform" Yes, I believe you. But do you also believe me, that the other group of people who do not need this procedure (and never needed it in their lifes) is equally large (or even larger), and that they would feel annoyed if we just put a "Print-2-pages-on-one-sheet-useful-for-people-who-want-duplexprints-on-a-simplex-only printer"-buttons alongside 2 dozen similar wizards somewhere? "You already explained the algorithm for doing this, so what would be the problem with putting all this functionality in just one button or checkbox or something to make the functionality more obvious?" And how many more "just one button or checkbox" do you want for some very specific tasks and task combinations to be performed? I could name you at least two dozen such/similar tasks, all related to printing, all asked for by users. Should we implement all of them? And if so, how can we at the same time a lean, elegant, non-confusing GUI and usability for KDE's printing dialogs? I *bet* implementing all of these as "single button clicks" and show this collection of buttons/checkboxes somewhere will not help users to find this more intuitive. I don't say the current implementation is intuitive, I just say: printing is a complicated business as soon as you think about not just your own needs as a home user with a single printer ("I want to click, and it should just print my 2 pages"). it is very difficult to make it good GUI frontend for it that satisfies most needs. I invite you to sit down and submit your ideas in a *meaningful* way. Alternatively, sit down and *implement* it yourself. Just for your own use. Make yourself one of these "I can make specific printing tasks easy" wizard: the one which is discussed here: the "Print-2-pages-on-one-sheet-useful-for-people-who-want-duplexprints-on-a-simplex-only printer"-wizard. You can do that in "Kommander". I hear one does not need to know about coding in ordert o produce useful mini-applications and wizards in Kommander. Once you've done it, publish it on http://kde-apps.org/. I'm sure you can find a few more people who will find it useful and would love it. And if you like the feedback, implement a few more of these wizards, until you can publish it as a "Box of Printing Wizards".... "I say we reopen this bug as such." And I say NO. (I should even have closed this bug as INVALID as such, not as DUPLICATE :-) Feel free to add a *new* bug report that deals with the "usability" problems of KDEPrint. I'll gladly keep it open until it is implemented (or forever), if it has attached convincing mockups or paperprototyping as I outlined above. But I'll close it very quickly again, if it is only 5 sentencses that can be summarized as "it needs to become better and more user-friendly, and now its usability sucks". Because that we know already even without a bug report. Cheers, Kurt
Kurt, Thanks for the extensive reply. I understand the points you are making, especially about the UI clutter of an additional button or checkbox. You need to understand that I filed the bug to help KDE function better with regard to my needs, and hopefully the needs of others too (which the popular vote in this case seems to confirm), and not to bitch and moan about how much kprinter sucks. You see, since I filed this bug in May 2004, I've encountered this situation some more times and it kept annoying me. All in all I've probably thought about it for far longer than an hour as you suggested :) Each time however, my conclusion was that this was a bug, and not a feature request, and therefore would need fixing instead of adding. I'll address this below. First, let me withdraw my comment about the additional button or checkbox. I was in a hurry and wanted to write something because this bug finally got a response other than a "me too!"-comment. Also, let me say that I appreciate the effort of the many developers and contributors of KDE (and its print system) a lot, especially those who investing their spare time in it. Each time I encountered this situation, I came to the conclusion that I couldn't think of a single reason why someone would use the odd/even printing functionality *other* than the situation I described: duplex printing on a simplex printer (thanks for pointing out the correct terms, btw ;) Now it's very possible that I've been too shortsighted, only thinking from my own perspective, but 2.5 years must say that at least it won't be a very common situation. I'm strengthened in this belief by your comment, in which you distinguish between the people-who-want-duplexprints-on-a-simplex-only-printer and the people-who-will-never-need-this-functionality-at-all, omitting the (possibly nonexistent) group of people who *need* the functionality as it is implemented now. Therefore my proposal is simple. If we can agree on the assumption that the people who would appreciate the functionality as I proposed is far larger than the group of people who don't, the default behavior should be altered to be the most sensible. No UI changes, no additional clutter. I sincerely believe that this is the case, but please (anybody) go out of your way and prove me wrong. If it turns out that there's a reasonably large group of people (or a reasonably common use-case) that would actually be harmed by a change in functionality, I will take your suggestion to heart and think about a sensible and non-intrusive UI improvement to implement this. If changing the default behavior creates another usability problem due to consistency issues, I'd be fine to postpone this change to KDE4, and introduce it along with the other major changes that version will bring. Please consider my proposal, I'm not trying to butcher kprinters usability, I'm trying to enhance it by providing a more sensible default. Also, since my proposal is *exactly* the same as in the original bug report, I once again propose to reopen. Sander
Created attachment 19288 [details] A printer instance named "make-my-printout-exactly-like-bug82123-reporter-wants-it" Example for a "printer instance" named "make-my-printout-exactly-like-bug82123-reporter-wants-it" that lets the reporter and his commenters access the exact setting that they seem to need so frequently with a single click, each time, until they delete or re-misconfigure it...
"duplex printing on a simplex printer" We already have a little helper applications (look in the list of the "pre-filters") that does *exactly* do this. And does so for "1 page on each side of a sheet" very well. It is not our fault that you want to stuff several functionalities onto one single stack: like, adding 2-up or 4-up page imposing to this "duplex print on simplex printers" one.... "the default behavior should be altered" No default behavior will be altered. Because it can't. The default behevior comes from the externel utilities. It is their defaults, not ours. We don't change externel utilities (even if we are convinced they should) unless we have *someone* *to* *do* *the* *work*. And we haven't. Simple as that. "I'd be fine to postpone this change to KDE4, and introduce it along with the other major changes that version will bring." You're funny. So *you* postpone a change, and *you* introduce it with KDE4? So *you* are going to do the work? Hey, 5 minutes ago you even found an excuse not to sit down and create mockups and paper prototypes... I can't believe you'll do an implementation. (But you'll need a mockup/paper-prototye for that as well, ya know?) And even if it's not you who does any coding -- unless we have good proposals, nothing will change in any case. No excuses, people! "my proposal is *exactly* the same as in the original bug report" ...and you got an *exact*, sane and well working solution to this supposed "silly bug", and you got shown how to do it in *current* KDEPrint. So why don't you just stuff this setup into a new "printer instance", save it and be done with it forever? You can then invoke this exact feature by simply selecting the "make-my-printout-like-bug82123-reporter-wants-it" printer (see attachment). "Please consider my proposal" I don't see a proposal. Which is it? When you have one, open a new bug report, and make a "precise" proposal, backed up with mockups/paper-prototyes etc. like I requested above. "I once again propose to reopen." No. This one is closed.