Summary: | Multiple pages per sheet: Pages are printed on top of each other | ||
---|---|---|---|
Product: | [Unmaintained] kdeprint | Reporter: | John Pye <john> |
Component: | general | Assignee: | KDEPrint Devel Mailinglist <kde-print-devel> |
Status: | CLOSED DUPLICATE | ||
Severity: | wishlist | CC: | jlayt |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Scanned 2-up output |
Description
John Pye
2005-06-08 10:35:51 UTC
This is due to the fact that n-up printing takes place at 2 different locations: once using the kdeprint-specific filtering ("Filters" tab) and the other on the server side ("Pages Per Sheet" option). I agree that this can be confusing. As you found it, you shouldn't turn on n-up printing on the server side if you do it already on the client side. This should be clean-up a little bit. Michael. I disagree that this is a 'wishlist' item. It's a bug... I had to spend quite a while working out what I'd done wrong htat was making pages be printed on top of each other. Perhaps I wasn't clear. In step 6, my page looked like this: +------+------+ | xxxx | yyyy | | xxxx | yyyy | | xxxx | yyyy | | xxxx | yyyy | +------+------+ Here, xxx is PAGE 1 FULLSIZE PRINTED ON TOP OF PAGE 5 FULLSIZE, and yyy is PAGE 2 PRINTED ON TOP OF PAGE 6. The words and images are overlaid on top of each other, it's definitely a bug. This is wrongly implemented functionality; there is no message given to alert the user the fact that this operation is disallowed or is going to have this effect. I wasted quite a bit of paper. How do the '2-up' functions work in these two different places? At the very least, if I select 2-up on bother the 'server' and the 'client' (not sure which is which here), then I would expect '4-up' printing rather than two overlaid sets of 2-up pages on the same sheet. It seems like the geometry of the 'pages' on the 'sheet' are not being correctly manipulated during the 'n-up' process on one or other of these processors. Created attachment 11375 [details]
Scanned 2-up output
Here is an scan of the bad output. Notice that there is type printed on top if
other type. Also note that the grey box on the right-hand side has behaved in
an opaque manner -- dunno if that helps narrow down the problem.
Cheers
JP
Normally, you should have had 4 pages on 1 (twice 2-up printing). The overlay problem might be due to various factors: problem with PDF file and/or the PDF viewer to produce DSC compliant PS data, incompatibility problem between the printer and the driver. What you can try is to generate first a PS file with the same "Filters" as you used. Then try to print the PS file using "lpr -o number-up=2 <the_file.ps>" to see if the problem still persists. Michael. Hi Michael Where does the '2-up' thing on the printer options window get done? It's not KDEPrint that does that? The print preview looked correct, is that not an acid test of the above issues? Is this a case of the same '2-up' filter being applied twice in succession, or does the '2-up' thingon the printer options work in another way? JP It's a little bit tricky and has to be cleaned up: when using a real physical printer, the 2-up option in the printer properties dialog is converted into a number-up-2 option sent to the CUPS server along with the file to print. As the preview occurs *before*, you won't see the result in the print preview. When using a pseudo-printer (like the print-to-PDF printer), the 2-up is faked by applying the psnup filter; in this case, the 2-up option is linked to the filter spec in the "Filters" tab. As this is âpplied *before* the file being sent, you'll see the result in the print preview. As a result, when using a real printer, you should not use the 2-up option in the "General" tab, with the psnup filter in the "Filters" tab because they are redundant (one on the client side, one on the server side). The print preview looks correct because you only see the result of the client-side processing. The additional server-side processing screws up the final result. Michael. John, the problem you describe sounds like one that was present in an older CUPS or Ghostscript version (can't remember which right now). Please see also the following list of URLS for... (a) possible duplicates of your bug report and (b) some hints about how you can work around and/or fix your problem locally To achieve an output as you describe (2-up/4-up), you can also make KDEPrint use its external pre-filters (disable the 2-up/4-up then in the main print dialog, otherwise it will be done repeatedly). The main dialog calls upon CUPS to do the layouting (which possibly runs on a remote, not the local machine), while the prefiltering will call an external tool named "psnup" on the local machine. For some ideas about automating this, see this link: http://www.kdedevelopers.org/node/2630 This is a duplicate of the following bugs: Bug 82123 : Printing odd/even pages with multiple pages per sheet gets silly results (DUPLICATE) Bug 107936 : [KDE4] multiple pages on one sheet not in right order NEW Bug 92962 : Option for number-up-layout=???? (page ordering on multiple pages) missing in kprinter (DUPLICATE) Bug 97669 : multipage reverse printouts in wrong order (DUPLICATE) Bug 103666 : [KDE4] facilitate margin adjustment for double-sided printing (DUPLICATE) Bug 108484 : printing multiple pages per sheet with reverse option selected (DUPLICATE) Please continue discussion at bug 107936 and transfer your bug votes if you care. Should you still have similar problems, don't miss to read the hints given in the comment section at bug 107936 and at bug 82123 before you open a new bug. *** This bug has been marked as a duplicate of 107936 *** Closing old Resolved status bug. |