Bug 97669

You selected the reverse option and you got the pages reversed, isn't that correct?

I can see two ways of viewing it:  you can reverse the order of the pages and send that stream of reversed pages to the printer, which is what happening.  Or you can print 4 pages to a sheet and then the sheets to the printer in reverse order, which is how Konqueror prints web pages. I would prefer the second behavior, because of how my printer accumulates the printed pages.

Reassinging to kdeprint as is not really a kpdf problem, 4 pages and such is all managed by kdeprint

read the whatsthis on the reverse checkbox (right click on the reverse option). The behavior as you mentioned its doing currently is consistent with the whatsthis.

But it inconsistent between applications:

Konqueror printing out a 7 page html document as

sheet 1:   sheet 2:
 5,6        1,2
 7          3,4

while Kpdf is printing out a 7 page pdf as

sheet 1:   sheet 2:
 7,6        3,2
 5,4        1

The way Konqueror is printing makes more sense to me.

First off: 

* did you do your tests just with the help of the "preview" option? 
* or did you "Print to PDF file" and investigate there?
* or is this what your printer spew out?

Note, that in the case of a real printer, this device might be driven by CUPS (is it so?, you didnt say), and the page layout may have been done the CUPS "pstops" filter (ordered by KDEPrint to do so.)

Note, that in the case of no real printer, or of a non-CUPS print subsystem, these features are handled by plugged in external programs and utilities. For more details about these "pre-filters", see below.

Next: Did you notice that there is one more printing option that may influence the outcome of your print job scenario?

--> It is the "Reverse portrait", and it tumbles the page images.

You can find this option if you...
 ...start kprinter from an application (note that kprinter started from the command line behaves different), 
 ...select the "Properties" button, 
 ...go to the "General" tab.

This should result in Konqueror in

  sheet 1:   sheet 2: 
      7        4,3 
    6,5        2,1

while in Kpdf in 
 
  sheet 1:   sheet 2: 
    4,5          1 
    6,7        2,3 
 

More questions:

* Did you, by any chance, print as duplex? (This could lead to kpdf [which knows in advance how many print pages there ar] to insert an empty additional page into the job.)

* Can you test if a simplex/duplex toggle changes either of Konqueror and kpdf's behaviours?

---------------
Some background: KDEPrint is really "only" a GUI frontend (albeit a very powerful one) to underlying programs. The "n-up" and "page revers" functions are in part executed by calling external pre-filters. You can look at the filters available on your system if you browse the "Filters" tab on your printer "Properties" dialog.

--> Driving the "Multiple Pages per Sheet" filter is "psnup".
--> Driving the "Page Selection/Ordering" filter is "psselect".

If your underlaying print subsystem is *not* CUPS, then the only possibilities to control such features are via these pre-filters. If you choose one of the KDEPrint "Special Printers" (such as "Print to File (PDF)" or "Mail PDF (KMail)") this is also the case.

If your underlaying print subsystem *is* in fact CUPS, then you may control such features via CUPS print commands ("-o outputorder=reverse", "-o number-up=16")

---

Last point: CUPS supports (since a few releases) much more finely grained control regarding the order of page imposition. Unfortunately KDEPrint and kprinter do not yet support these in the GUI. (Note: in order to take advantage of these, you *must* disable all pre-filters in KDEPrint in order to avoid unexpected side-effects):

The "-o number-up-layout=value" CUPS parameter controls layout of pages on each output sheet:

-o number-up-layout=lrtb   # left to right, then top to bottom (default)
-o number-up-layout=lrbt   # left to right, then bottom to top
-o number-up-layout=btlr   # bottom to top, then left to right
-o number-up-layout=btrl   # bottom to top, then right to left
-o number-up-layout=rlbt   # right to left, then bottom to top
-o number-up-layout=rltb   # right to left, then top to bottom
-o number-up-layout=tblr   # top to bottom, then left to right
-o number-up-layout=tbrl   # top to bottom, then right to left

Cheers,
Kurt

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

Thanks Kurt for all your help.

Those were the results of actual printing: a HP PSC 1210 via CUPS (no duplex &
prints out pages face up with later pages stacked on top of earlier pages - hence the reason for wanting a reverse printout - so I wouldn't have to do it manually).

Preview didn't even show the pages as 4-up, just individual pages.  It also differs between konqueror (which doesn't reverse the pages in preview) and KPDF (which does).

Trying the reverse portrait option just changed the direction the page came out of the printer.  The pages still had the same layout relative to each other.

Invoking kprinter from the command line "kprinter -o outputorder=reverse -o number-up=4" on the pdf did give the desired results (i.e. like Konqueror prints web pages).  Any idea why this differs from printing from KPDF with those options selected from the GUI?  It's confusing that different applications are combining those options in different ways (if they both had printed out the other way I wouldn't have considered it a bug, just 2 features that didn't work well together).

Thanks again,
 Eric

The difference comes from the fact that the 2 operations involved - n-up and reverse/selection - can be done at different places. KPDF is able to handle page selection and reverse, this reduce the data sent to the printer, while n-up is left to the CUPS server. Konqueror relies on CUPS for both operation. Unfortunately, CUPS processes reverse (and probably page selection) *after* processing n-up. In the case of KPDF, reverse operation will always be done *before*, because it's not done by CUPS.

This is not a fix, but it explains the difference that exists between apps that are page-based (kwrite, konqueror, kword...) and the others (konqueror...). KDEPrint tries to provide all features to all applications and to be optimal at the same time (I could for example rely entirely on CUPS for page selection, but this means that the app would have to print all pages everytime, and I guess you don't want to print all pages of a 500-pages PDF file, just to print a single one...). Of course, it's sometime very difficult to be consistent for all apps with the large number of possible option combinations...

Michael.

I decided not to open a new bug, but maybe it is...

I wanted to print 4 pages per sheet in landscape mode.
(in fact landscape is used even if i do not select it because the pages are wider than high)
The result is:
3 1
4 2
so i tried    kprinter -o number-up=4 -o number-up-layout=lrtb "file"
like mentioned above.
but that leads to the message "nothing to do" when i hit print in the upcoming dialag

i cannot use the filter n-up (nor the most others) because it says s.th. like "not available: unsatisfied requirements" (why?)

im using an HP Laserjet 6L with cups.

You need the psutils package installed. Most of the filters rely on the utilities of this package: psnup, psbook, psselect....

Thanks, Michael.

n-up produces exactly the same (wrong) output...
so i tried to "cheat": print 2 pages per sheet into a file.
(the original document is landscape)
result is (as expected):
[1]
[2]
===
[3]
[4]

but trying to print THIS out on the printer or into a file STILL leads to the wrong layout:     expected:
[3][1]            [1][3]
[4][2]            [2][4]

so... are there any chances to print out my landscape-pdf in the expected layout?
i think it would be a nice feature to create a multipage layout graphicaly:
select colums / lines (e.g. 2x2), flip / rotate each single page

in the meanwhile i'd be happy to get an advice how to print it out in the way i want anyway. thanks :)

I'm starting to wonder if the problem is not the PDF file itself...
Normally, you should be able to do what you want using plain command-line tools, without kprinter. Use "pdf2ps" to convert your file to PS, then "psnup" to layout it as you want. Once you have created the final PS, send it to the printer using "lpr".

Michael.

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

The problem is the document being landscape.
There is an option in psnup (I think it is -l) to fix multiple pages per sheet of landscape documents, but kprinter doesn't make use of it.

Hmm, I justed wanted to file a report for this too. (I'll add it at the end.) I understand that the interaction of the different components of the print system are quite complex. Anyway, is there any hope of seeing this fixed? At least in the non-duplex, 2-up, portrait, it is clear what should happen. Oh, and please don't get me wrong, kprint is very powerful and I really appreciate that!

I found comment #9 to be quite interesting, but now I'm wondering why KDE doesn't always do the page composition. After all, this would give more power to the KDE print system. Reversing the page order and letting CUPS do 2-up is obviously wrong. (And I'd even say that it'd be better to disable this combination than letting the user waste lots of paper...) If page composition were handled by KDE, CUPS would only need to print the stream of pages. At least in the case of the original report, printing could be fixed by doing the n-up in kprinter.

So, here's my report. This happened while printing a pdf (on a real printer) in kpdf. I retested with the "print to pdf" printer. In both cases the result was something like this:

-----
|5|4|
-----
-----
|3|2|
-----
-----
|1| |
-----

instead of

-----
|5| |
-----
-----
|3|4|
-----
-----
|1|2|
-----

In other words, reversing and putting two pages on one are in the wrong order. I doubt that anyone would want the pages in the wrong order. Obviously, "Reverse" is intended to have the pages in the right order when they come out of the printer, independently of the 2-up setting. As you can see, this is currently broken.

Indeed, I also thought about letting KDE do the page composition as a potential solution, but it also have drawbacks.
Pros:
- independent of the print system (available for all)
- more consistency between real- and pseudo-printers
Cons:
- depends on external programs that *must* be installed (psutils package)
- you don't have access to any improvements CUPS could bring to its composition implementation

I think that one has to consider what most users intend when using reversed. I am pretty sure that they do not expect the page-order just to be reversed, but the printing-order to be reversed. Actually I cannot remember any situation, where I wanted to have the pages re-ordered. The fact that reversed works for single pages is just a coincidence, as in that case reversing the page-order has the same result as reversing the print-order.
IMHO opinion the reverse-functionality should be re-labled/re-worked to "Reverse printing-order", "Print last (multi-)page first" or something similar, that reflects the needs and expectations of the majority of users.

As it has been some time, I am not too sure, but what is the default functionality of the windows-drivers supplied by the major printer-manufacturers? Be it due to users getting used to their way, or due to them having researched users needs, I think that they work the "reverse printing-order"-way and not the "reverse page-order"-way.

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

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

The topic of "number-up" printing and the order of the layed out pages, as well as "number-up" in combination with "page-selection", "reverse-ordering" and the like are discussed at a number of places here in KDE Bugzilla:

  * Bug 82123   : Printing odd/even pages with multiple pages per sheet gets silly results
  * Bug 107936  : [KDE4] multiple pages on one sheet not in right order  NEW

These are the most important two. And there are (were) more: 

  * Bug 92962   : Option for number-up-layout=???? (page ordering on multiple pages) missing in kprinter
  * Bug 97669   : multipage reverse printouts in wrong order (this one)
  * Bug 103666  : [KDE4] facilitate margin adjustment for double-sided printing
  * Bug 108484  : printing multiple pages per sheet with reverse option selected

Reporters and commenters, please take note of these facts:

 * KDEPrint does not do *any* processing of the original print file on its own.
 * KDEPrint utilizes external tools (and combinations/pipes thereof)
 * KDEPrint is a GUI front to make possible and easier tasks usually run on ClI
 * KDEPrint as a frontend can not fix bugs or deficiencies in the used utilities
 * You have to live with the defiencies of these tools

And more:

 * Notwithstanding a real bug in one of the tools, I guarantee you that all 
   described requirements regarding combinations of n-up, page-selection and 
   reversing that you named in your various bug reports can be done with
   KDEPrint (and its external helper utilities) *even now* (and more)! And
   it can be automated (so you don't need to set up the details every time 
   again) simply by creating a "printer instance" that immortalizes within 
   itself all the settings that you once shed your blood, sweat and tears for
   to get right... 


We welcome any well worked out suggestions to a good new GUI for KDE4's KDEPrint. Create mockups, make paper prototypes, use your drawing skills.

Unless that doesn't happen, KDEPrint4 will basically be the same as it is now.

And even if it does happen, we will not automatically have someone with the time, commitment and skill to sit down and write the new code. Simple as that. 

Closing this bug now for good as a duplicate. 

Please transfer your bug votes to bug 107936 if you care. Please continue this discussion at bug 107936. Please make sure you read the other threads in the bugs listed at the beginning of this posting, and study some of the detailed hints and tips+tricks and screenshots (!!!) (esp. at bug 82123 and bug 107936) before you opine about this again.

Thanks.



*** This bug has been marked as a duplicate of 107936 ***