Summary: | [KDE4] Make selection for layout order of "multiple pages on one sheet" more easy | ||
---|---|---|---|
Product: | [Unmaintained] kdeprint | Reporter: | hene wou <hwouters> |
Component: | general | Assignee: | KDEPrint Devel Mailinglist <kde-print-devel> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | wishlist | CC: | alvaro.aguilera, arekm, barbour, bugzilla, curdyben, ebrahim, ems31, Erwin.Mascher, esigra, jlayt, john, kyron, mail, phlogi1, stefan-tiger |
Priority: | NOR | Keywords: | rtl |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Setting kprinter on "Additional Tags" tab for layout-control in n-up printing
8-page KWord document in 9-up in "top-to-bottom, right-to-left" layout 8-page KWord document in 9-up in "top-to-bottom, left-to-right" layout 8-page KWord document in 9-up in "top-to-bottom, right-to-left" layout |
Description
hene wou
2005-06-22 22:24:14 UTC
UNCONFIRMED (batch reassigning messed this) What application do you use to generate/print the slides? I also have this 'problem'. First I converted with Openoffice a presentation to pdf. The resulting pdf is looking fine. Then I use kpdf to print 8 sheets on one page (with using filters). However the pages are printed in the following way: 5, 1 6, 2 7, 3 8, 4 More logically would be: 1, 2 3, 4 5, 6 7, 8 Or: 1, 5 2, 6 3, 7 4, 8 It would be nice if this behaviour can be implemented :) Please change to "wishlist" as it is not a real bug. The problem can be reproduced very easily by printing a slide show in landscape format (some Powerpoint presentation intended for viewing on monitor, for example) using the '4 pages on one sheet' option. In this case a page in landscape format will be printed with the first to pages/slides on the right side and the last two on the left, which is wrong. That is, if the slide is in "Portrait" orientation the function works fine. Problem is, kprinter doesn't detect anything and the user can not tell anything either. If possible the little picture showing the result should have numbers instead of only rows representing the text and it schould show where which page will end up (on top it should be combined with the orientation icon/picture). On top of this, the "Landscape"/"Portrait" switch should determine in which order to print, showing the result in a single, somewhat bigger icon/picture (why are there two icons/pictures anyway?). Workaround: To print 4 in 1 in landscape orientation correctly, you have to manually enter page numbers and always enter the two last slides of the page first, then the two first slides, i.e. 3,4,1,2,7,8,5,6, ... For OOo, there is a way of doing this within OOo. Please see manual as it depends on which component (Writer/Impress) you use and well, it's not really convenient/easy to explain. No need to say that this is really anyoing. That is, thanks for the good work. PS: I have KDE 3.4.2 on Mandriva 2006, if this is of any help. I have the same problem for my gentoo system, but I think I found the underlying problem. psnup is used to put multiple pages on one sheet. It has a switch (-l) for landscape mode. When printing multiple pages, psnup is called from kprinter like psnup -pa4 -4 /tmp/kde-cbswrqzIx/kpdfInIrab.ps. If the -l flag is added, then the output is as expected. OK, I've played arround in the kprinter filters and added that -l option. It works now, but really, thats not something every user would be able to do without good instructions. On top, changing settings in the filter tab is really horrible, as you easily forget to change settings back there (you have printed your nice 4in1 landscape slideshow yesterday but today you want to print some document in "portrait" orientation and one page per page but what comes out? Yes, the 4in1 landscape you configured a day ago). Kprinter should really be corrected that way that if multiple pages are selected WITH landscape mode, the -l option should be passed to psnup. I just don't see how what comes out with actual default settings can be of any use ... Btw Adobe Reader 7.0.5 has a really nice GUI for printing showing how the page should be printed ... with the little problem that it just shrinks what you see in the preview on a "portrait" oriented page ... not what you wanted and have seen! Argh! But OK, that's a different story. I think there should be two additional options in filter "Multiple Pages per Sheet Filter": A boolean value for landscape orientation (value for true is "-l" and value for false is empty string, default=false) or you use values from print dialog. In any case a "Column-oriented" value with true value = "-c" would be really convenient for change orientation of pages. *** This bug has been confirmed by popular vote. *** Created attachment 19266 [details]
Setting kprinter on "Additional Tags" tab for layout-control in n-up printing
Created attachment 19267 [details]
8-page KWord document in 9-up in "top-to-bottom, right-to-left" layout
Created attachment 19268 [details]
8-page KWord document in 9-up in "top-to-bottom, left-to-right" layout
Created attachment 19269 [details]
8-page KWord document in 9-up in "top-to-bottom, right-to-left" layout
If the number-up layout is done by CUPS... there are (since quite some time) these options available for sorting: (a) -o number-up-layout=btlr ; Bottom to top, left to right (b) -o number-up-layout=btrl ; Bottom to top, right to left (c) -o number-up-layout=lrbt ; Left to right, bottom to top (d) -o number-up-layout=lrtb ; Left to right, top to bottom (default) (e) -o number-up-layout=rlbt ; Right to left, bottom to top (f) -o number-up-layout=rltb ; Right to left, top to bottom (g) -o number-up-layout=tblr ; Top to bottom, left to right (h) -o number-up-layout=tbrl ; Top to bottom, right to left This certainly is a feature we should support properly in the GUI. For now, if you need full control, follow this procedure: --> Do *not* select number-up in the GUI (!!) --> Instead, insert the wanted number-up details in the "Additional Tags" tab. Note, you will not see the number-up layout in the print preview, because the layouting happens later in the printpath, once the job has reached the realm of CUPS. You can even control wether there should be drawn borders around the frames, and which style: (a) -o page-border=double ; draw two hairline borders around each page (b) -o page-border=double-thick ; draw two 1pt borders around each page (c) -o page-border=none ; do not draw a border (default) (d) -o page-border=single ; draw one hairline border around each page (e) -o page-border=single-thick ; draw one 1pt border around each page I printed an 8 page document from KWord, using these n-up settings: --> number-up=9 --> number-up-layout=tblr Now look at the screenshots: * http://bugs.kde.org/attachment.cgi?id=19266&action=edit (Setting kprinter on "Additional Tags" tab for layout-control in n-up printing) * http://bugs.kde.org/attachment.cgi?id=19268&action=edit (8-page KWord document in 9-up in "top-to-bottom, left-to-right" layout) * http://bugs.kde.org/attachment.cgi?id=19269&action=edit (8-page KWord document in 9-up in "top-to-bottom, right-to-left" layout) As you can see, it worked exactly as expected. Cheers, Kurt *** Bug 103276 has been marked as a duplicate of this bug. *** *** Bug 82123 has been marked as a duplicate of this bug. *** *** Bug 129273 has been marked as a duplicate of this bug. *** Would that also properly handle the "print even pages"/"print odd pages" option with n-up prints? (This is what #82123 was regarding, BTW.) Brendon, it is already *now* possible to achieve with kprinter what the reporter of bug 82123 did want to do. Just use the "pre-filtering" feature, and just combine two prefilters (in the correct order). See my additional comments there for details (and the screenshots I made). Thanks. *** Bug 103666 has been marked as a duplicate of this bug. *** *** Bug 97669 has been marked as a duplicate of this bug. *** *** Bug 91626 has been marked as a duplicate of this bug. *** *** Bug 107018 has been marked as a duplicate of this bug. *** Hello, just as you suggested, I've made a mockup and a suggestion to improve the way that filters are handled in the printing dialog, but I don't know if that's now possible given that kprint uses only external tools (I'm referring to the live preview). Anyway, here is the suggestion: http://www.kde-look.org/content/show.php?content=51829 Looking at the possibilities that QT4 has through Arthur, would it be possible to apply a chain of effects to a document with QT and then send the output to pdf just to print? well, there is already a patch for that since 2005 (Bug #52151), but nobody seems to care about it enough :) On 29 January 2007 05:40, Erwin Mascher wrote: Hmmm... I already did the work to integrate that. I thought I already committed... Ough! I will check what happened on my side and try to complete as necessary, time given. Thanks for signaling. Changed $summary of this bug. Old summary saying "multiple pages on one sheet not in right order" does not really match what is left as substance from this submission. The ultimate question is, is it integrated in KDE4? (as per Comment #25's intention) KDE4 supports n-up through CUPS and supports the full set of Cups page-order options and page borders. This is user-selectable not automatic though, i.e. does not look at landscape setting or RTL setting to change order automatically as originally requested. The order of n-up is still broken on kubuntu for example. I think I can clear up some of the recurring confusion here. I was struggling with this myself. Use case: I want to print a lecture pdf 4-up as a condensed handout for students. I change nothing except the "4 pages per sheet" option in the "properties" menu of the kprinter dialogue. In particular, the default portrait option is always active (the print system seems to rotate the landscape slides automatically when printing 1 page per sheet). The 4up output page order appears wrong. Viewed as *landscape* (imposed by the orientation of the slides), I get top-right, bot-right, top-left, bot-left. The suggested solution is to add "number-up-layout / <option>" to Additional tags in the kprinter dialogue, where option is something like "lrtb". You go blue in the face telling it you want "lrtb" (or "tblr"), but the first slide will always be annoyingly on the right, not top-left. There are eight options (and you can throw in the landscape selection etc). You get lost in option combination space. The real solution is to realise that the printing is still occurring in *portrait*, so the top-left of the page as you read it was in fact the bottom-left corner when printing in the portrait orientation. You subconsciously rotate the page before reading it. The option "lrbt" (or "btlr") for the default portrait orientation should then give the expected output when switching from 1 page per sheet to 4-up without changing other options (it works for me in Debian testing; KDE 3.5). This will only be active during n-up printing and should therefore not intrude much otherwise. It is not a general solution, though. This is something of a black hole for users: - a very obscure configuration option (even users who know about "what's this" and think to click IN the additional tags dialog and not ON its tab get a general description that refers to the cups manual; certainly nobody's grandmother or even a nobel laureate will get that far and read the manual to find the correct option, even more so it they don't even know it exists!!!!!) - awkward interaction of automagic (rotation of landscape to portrait) with a bewildering mix of obvious options (portrait, landscape, reverse landscape...) and 8 hidden layout options "lrtb", "rltb", etc. How many combinations?? - simply switching to landscape (without the additional tag) did not work for me. This needs to be addressed systematically, taking all parameters into account (page orientation, orientation setting, paper orientation, number of pages per sheet, etc...) It may be possible to reduce the option combination space to a few automagic switches that can do the "right things". Or it may be necessary to expose a very detailed and explicit menu. But this is a very useful feature and it would be satisfying to get it right. KDEPrint is obsolete, unmaintained and will never be revived. Closing all open bugs. I think someone should check whether this bug still exists in KDE or not before closing it. If the problem is still there, then this bug report should be renamed or merged with an current one. I suspect many people still refer to the newer printing system in KDE as "KDEprint". |