This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 422661 - wrong order when printing multiple slides per page
wrong order when printing multiple slides per page
Product: Fedora
Classification: Fedora
Component: (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
: Desktop
: 431012 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-12-12 18:11 EST by Jack Tanner
Modified: 2008-02-06 12:41 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-06 12:41:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sample file (23.53 KB, application/postscript)
2007-12-14 04:51 EST, Jan Navratil
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 512571 None None None Never 85643 None None None Never

  None (edit)
Description Jack Tanner 2007-12-12 18:11:02 EST
Description of problem:

Impress places pages in the wrong order when printing presentations such that
there are 4 slides on a page in landscape mode. It uses the same ordering as for
portrait-oriented pages, and it shouldn't.

Version-Release number of selected component (if applicable):

How reproducible:

Print 4 slides per page in landscape.

Actual results:

  3   1
  4   2

Expected results:

  1   2
  3   4
Comment 1 Caolan McNamara 2007-12-13 04:02:45 EST
psprint/source/printer/cupsmgr.cxx CUPSManager::endSpool enable the debugging
stuff, capture the output .ps file of $HOME/ and all the options
passed to cups

IIRC we just send a relatively simple .ps file which is just one slide per page
and ask cups to do the x per page thing, so ideally we need to reproduce without
OOo in the picture, but just lpr list-of-options-we-used and ask twaugh
if we're doing it wrong or if its his problem

I believe this can only arise from the gnome printing dialog as the "native OOo"
one doesn't offer the ability to create multiple pages per slide easily.
Comment 2 Jan Navratil 2007-12-13 04:54:05 EST
jnavrati->twaugh: I can reproduce this without OOo as well. The following
options are passed to lpr:
    option Booklet=None
    option ColorModel=Gray
    option PageSize=Letter
    option InputSlot=Auto
    option Duplex=None
    option Gutter=None
    option Finishing=Col
    option Interleave=None
    option number-up=4
    option copies=1
    option job-priority=50
    option job-sheets=none,none

Is this correct or not?
Comment 3 Tim Waugh 2007-12-13 09:48:12 EST
I can't get this to go wrong here using just CUPS.  Jan, please attach your test
input file and the command line you used to print it.

For reference, here is what I tried:

$ echo -e '\n\n1\n\014\n\n2\n\014\n\n3\n\014\n\n4\n' > 4.txt
$ lp -onumber-up=4 -oorientation-requested=4 -odocument-format=text/html 4.txt
|1   2   |
|3   4   |
+--------+ (correct: lrtb)

$ lp -onumber-up=4 -odocument-format=text/html 4.txt
|1  2  |
|      |
|3  4  |
|      |
+------+ (correct: lrtb)

(The -odocument-format=text/html part is to force the use of the CUPS texttops
filter rather than our texttopaps filter, so that it's just CUPS being used.)
Comment 5 Jan Navratil 2007-12-14 04:51:46 EST
Created attachment 288971 [details]
sample file

->twaugh: I just copy/paste the above list of options to the command line and
print the attached sample file. i.e.
lpr -P Canon -o Booklet=None -o ColorModel=Gray -o PageSize=Letter -o
InputSlot=Auto -o Duplex=None -o Gutter=None -o Finishing=Col -o
Interleave=None -o number-up=4 -o copies=1 -o job-priority=50 -o
Comment 6 Tim Waugh 2007-12-14 06:35:47 EST
CUPS is behaving correctly as far as I can tell.  Viewing the input PostScript
using evince, I see four portrait pages:

Page 1: "A" tilted on its left side
Page 2: "B" tilted on its left side
Page 3: "C" tilted on its left side
Page 4: "D" tilted on its left side

This is getting printed with number-up=4 exactly as in comment #3 (second example):

|1  2  |
|      |
|3  4  |
|      |

with "1" above representing an "A" tilted on its left side etc.
Comment 7 Tim Waugh 2007-12-14 06:44:45 EST
I can get the output you expect by first rotating it, and then printing it

I rotated it like this:

/usr/lib/cups/filter/pstops 1 tim '' 1 'landscape' >

This gives a file that consists of four landscape pages:
Page 1: A
Page 2: B
Page 3: C
Page 4: D

Then I printed it like this:

lp -o Booklet=None -o ColorModel=Gray -o PageSize=A4 -o InputSlot=Auto -o
Duplex=None -o Gutter=None -o Finishing=Col -o Interleave=None -o number-up=4 -o
copies=1 -o job-priority=50 -o job-sheets=none,none -o landscape

(Note the addition of '-o landscape')

This gave me the following output, which I think is what you are hoping for:

|A   B   |
|C   D   |

So the solution is that needs to submit the document in its
"upright" form, whichever orientation that is, and get CUPS to do any rotation
Comment 8 Caolan McNamara 2007-12-14 06:58:52 EST
Maybe a little hack with rData.m_eOrientation to use the landscape option on as
propogated down directly from the gnome print dialog. I don't think we want to
tell the OOo layout itself about that, but just tell cups at the end. That might
bring us closer.
Comment 9 Caolan McNamara 2008-01-28 09:54:40 EST
Sigh, the ideal solution from my side would be to stick a %%PageOrientation on
each landscape page and have the cups tooling take notice of that to figure out
the "human's perspective" of what way each input page should be orientated. 

Ideally OOo shouldn't really know when printing that the ultimate destination is
some n-up situation, but the rotation to create a landscape page causes trouble
in n-uping such landscape pages. So to get this to work, we'd probably have to
hack this a good bit in that OOo would have a special case for n-up printing and
instead of rotating the text onto the page but instead swap the width and height
and not rotate.

Always one must also keep in mind that something like OOo can quite happily
output multipages of different orientations and sizes. So a document does not
necessarily consist of pages of equal orientation, so it's be a fragile
solution, but hopefully work for 95% of the use-cases.

Might as well file some bugs against our preview software anyway
( wrt. PageOrientation and
spread the misery around a bit.
Comment 10 Caolan McNamara 2008-01-28 14:35:00 EST
Yeah, this is doable. Definitely doable.
Comment 11 Caolan McNamara 2008-01-29 06:58:42 EST
will be in >= 2.4.0-5.2
Comment 12 Caolan McNamara 2008-01-31 03:09:58 EST
*** Bug 431012 has been marked as a duplicate of this bug. ***
Comment 13 Jack Tanner 2008-01-31 10:40:05 EST
Since comment #9 implies that documents with mixed orientations will be broken,
should there be a bug filed against cups?
Comment 14 Caolan McNamara 2008-02-06 12:41:56 EST
well, I'm not sure if mixed orientation is "broken" but its hard to know what
*should* happen. With this patch I think it will fit the humans expectation in
that all pages are orientated to the orientation that a human would use to read
them after they've been printed one-per-page and then that's sent for n-ups

But there might be cases where this isn't desired and a more vague heuristic of
"if they're *all* landscape then flip the lot, but if there's a mix then flip
none, or a "lets take a majority vote on the matter".

Or even it might be argued that e.g. OOo and so on should do nothing at all, and
stick %Orientation and %PageOrientation directives into the ps (which it now
also does so that pages appear rotated the "right way" in e.g. gv and future
evince) and that cups n-ups printing would do per-page rotation itself based on
those hints (maybe optionally, requiring a toggle button in the gtk-unix-print
dialog of gtk) 

Note You need to log in before you can comment on or make changes to this bug.