Bug 216332

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

This is still a problem, i.e. it didn't get magically fixed with the last OOo
FC-6 update ?

Still a problem.
openoffice.org-core-2.0.4-5.5.10

hmm, indeed. looks like we just don't use cups for any of this stuff. Perhaps
the best thing would be to just chop out all the OOo multi platform DIY magic
and make it make simple single copies and let cups do all this foo for it.

Created attachment 153865 [details]
replacement /usr/lib/openoffice.org/program/libsvt680li.so

So (on FC-7) does replacing /usr/lib/openoffice.org/program/libsvt680li.so with
this attachment "do the right thing(tm)" ?

No, it doesn't.

Printing two copies of a single-page document results in four sheets coming from
the printer, the first and third of which contain the document.

Printing one copy of a 2-page document results in two complete double-sided
sheets containing the document, i.e. two copies instead of one!

That's depressing, I thought that would work :=) I must be missing something
obvious. I don't get the extra pages on my non-duplex. With the above OOo itself
should just be giving cups a simple single copy of the .ps with no /ncopies or
self made extra copies. i.e setting 2 copies and collate on or off and print to
file should show in evince a single page, and grep pages output.ps should show
nothing. So if the above holds for you as well, I must assume I'm passing cups
incorrect options, or doing something very obviously wrong.

I'll attach another replacement .so which will replace
/usr/lib/openoffice.org2.0/program/libpsp680.so

That lib will on stdout output the cups options used to print the .ps, and copy
the generated .ps to ~/cupsprint.ps, maybe if you've the time to check it out,
something obvious will jump out at you.

Created attachment 153930 [details]
replacement verbose /usr/lib/openoffice.org/program/libpsp680li.so

Okay, the extra pages were partly due to an incorrect page size in my test
document.  However, even with that corrected I still get an extra sheet fed
after a 1-copy 1-page print.  Haven't managed to track down why yet.

1-copy 2-page print correctly feeds one sheet and prints on both sides.

2-copy 3-page print incorrectly prints on first side of first sheet and ejects,
first side of second sheet (upside down), then feeds another two sheets blank. 
It's a complete disaster in all sorts of ways.

However, I'm not sure I can trust the hardware any more.  Rebooting to
known-good software (RHEL-5) shows the same behaviour. :-(

Created attachment 154009 [details]
replacement /usr/lib64/openoffice.org/program/libsvt680li.so

64bit equivalents

Created attachment 154010 [details]
replacement verbose /usr/lib64/openoffice.org/program/libpsp680li.so

64bit version

caolanm->jnavrati: I only have one printer here, and it doesn't do duplex :-( I
don't get any of the extra empty pages etc on such a simple printer. Can you
give this a whirl with a duplex printer in your office and see if you get the
same behaviour as twaugh when the various duplex options with or without collate
is enabled.

All that the above .sos should do is tell the OOo core from the print dialog
that we want just want a simple single copy .ps output to the printer no matter
how many we ask to print, and then at the actual cups print time we tell cups
that we had wanted to do Duplex and how many copies we had wanted. Cutting the
OOo core out of the loop and pushing the work to cups. What options we want cups
to use should be output on standard output.

twaugh: The replacements sos also make a copy of the printed .ps to
"~/cupsprint.ps", perhaps if you just take that .ps output and from the command
line print it with lpr and set the num copies and duplex etc we can see if the
behaviour is the same as from using print in OOo. I suppose if it behaves the
same, that the remaining comparison would be against what happens on printing
from the command line ps generated from e.g. gedit

caolan: I hope to get replacement hardware in the next week or two.  Without
reliable hardware there's not a lot I can do to help test it.  I did try to
submit the PostScript outside of OpenOffice.org, and with different options, but
as I said a known-working software set up also failed.

There's no major hurry, it's been like this for years already so I don't intend
to make any printing changes just before FC-7 anyway. When I get my next build
sorted out, then jnavrati may be able to test the above x86_64 replacements in
brnu where there's reportedly a few expensive multi-featured printers. If we
finally get this sorted out and working in rawhide then we might backport.

Okay, tested with a replacement duplex printer, and all works fine.

cupsPrintFile( DESKJET_980C, /tmp/F8PEcB, Untitled1, 10, 0x976f1f0 ) returns 35
    option PrintoutMode=Normal
    option copies=2
    option InputSlot=Default
    option job-priority=50
    option Collate=True
    option number-up=1
    option Quality=FromPrintoutMode
    option job-sheets=none,none
    option PageSize=A4
    option Duplex=DuplexNoTumble

THis was for two copies of a three-page document, and I got:

front  back
+---+  +---+
|1  |  |2  |
|   |<>|   |
|   |  |   |
+---+  +---+

+---+  +---+
|3  |  |   |
|   |<>|   |
|   |  |   |
+---+  +---+

as expected.

This was with the drop-in bits, libsvt680li.so and libpsp680li.so, on Fedora 7.

For what it's worth, I also tried the same test from Fedora Core 6 and *that*
works fine now too (openoffice.org-core-2.0.4-5.5.22) -- however, the "let CUPS
figure it out" approach is the way forward anyway I think.

By the way, the cupsprint.ps file still has several '%%IncludeFeature:' clauses
-- I don't think we need them now do we?  E.g.:

[{
%%IncludeFeature: *PrintoutMode Normal
} stopped cleartomark
[{
%%IncludeFeature: *Quality FromPrintoutMode
} stopped cleartomark
[{
%%IncludeFeature: *InputSlot Default
} stopped cleartomark
[{
%%IncludeFeature: *PageSize A4
} stopped cleartomark
[{
%%IncludeFeature: *Duplex DuplexNoTumble
} stopped cleartomark

Removing those lines from the PostScript file and submitting it again with the
options it had before gives the same end result.

groovy, I'll do this for > FC-7 then. Printing is too much of a mine field to
enter right before a release.

Yeah, I also need to remove those IncludeFeature things. What I want to do is
just to remove them if we print from the gnomeprint dialog, but leave them there
if printing from the "traditional" dialog. Gives is an escape hatch route of a
"does it work if you try the other dialog" nature.

Sounds good!

Created attachment 154386 [details]
park this here in case I delete it or do something else equally stupid

checked in to devel, will be in F-8

openoffice.org-2.2.1-18.1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.