psprint/source/printer/cupsmgr.cxx CUPSManager::endSpool enable the debugging
stuff, capture the output .ps file of $HOME/cupsprint.ps 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 file.ps 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.

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?

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.)

Potential dupes upstream:

http://bugzilla.gnome.org/show_bug.cgi?id=449776
http://bugzilla.gnome.org/show_bug.cgi?id=420335

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
job-sheets=none,none cupsprint.ps

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.

I can get the output you expect by first rotating it, and then printing it
landscape.

I rotated it like this:

/usr/lib/cups/filter/pstops 1 tim '' 1 'landscape' cupsprint.ps > landscape.ps

This gives a landscape.ps 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 landscape.ps

(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 OpenOffice.org needs to submit the document in its
"upright" form, whichever orientation that is, and get CUPS to do any rotation
required.

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.

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
(http://bugzilla.gnome.org/show_bug.cgi?id=512571) wrt. PageOrientation and
spread the misery around a bit.

Yeah, this is doable. Definitely doable.

will be in >= 2.4.0-5.2

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

Since comment #9 implies that documents with mixed orientations will be broken,
should there be a bug filed against cups?

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
printing, 

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)