Issue 22304

Summary: OOo prints multiple copies of a document incorrectly
Product: gsl Reporter: pmladek <pmladek>
Component: codeAssignee: philipp.lohmann
Status: CLOSED FIXED QA Contact: issues@gsl <issues>
Severity: Trivial    
Priority: P3 CC: cno, issues, jr, kpalagin, orion, pavel, strada, utomo.prawiro
Version: OOo 1.1   
Target Milestone: AOO PleaseHelp   
Hardware: PC   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
The Sharp PPD file none

Description pmladek 2003-11-10 11:06:57 UTC
The problem:

If you print multiple copies of a document from (selecte more
than 1 in printing popup), OOo creates document where all pages are repeated as
many times as the number copies specified. On normal printer, it is fine, but
brings problem on duplex printers (in cases of documents with odd number of
pages) or some finishers (eg. staples all copies together).

My colleague has made some investigation. Here is his result:

There are 2 independent bugs:

1) OOo forces 1 copy.

2) OOo does not properly parse collate capabilities and forces sending pages n

In all cases except stapled document, these bugs cancels each other.

Problematic parts of code:

1) psprint/source/printergfx/printerjob.cxx

Hardwires single copy to PostScript file. It potentially collides with commands
from PPD file or print spooler.

2) vcl/unx/source/gdi/salprnpsp.cxx

Says, that UNIX lpr is not capable to collate documents. Even though it is true,
many spoolers are able to set it via -o.

3) vcl/source/gdi/print.cxx

If printer is not capable to do multiple copies or collating, prints phasically
n copies.


1) Don't try to set anything and let cups do the stuff.

2) Fast fix: Close output after each copy.

3) Full fix:

a) Fix psprint/source/printergfx/printerjob.cxx. It is bad idea to hardwire such
command to PostScript without ask. Especially if it is not OK (it hardwires 1
copies, not #copies).

b) Fix PPD parsing code and/or feature code, to be able to use printers' collate
Comment 1 utomo99 2003-11-10 11:10:26 UTC
is this only happens with Writer, or also with another applications ? 

Utomo > hi:
For printing I think it is GSL issue 
Comment 2 pmladek 2003-11-10 12:39:44 UTC
It happens with other applications as well. It really seems
to be a common printig bug.
Comment 3 utomo99 2003-11-11 02:43:41 UTC
change to GSL component, because it happens in all printing, not only
Comment 4 utomo99 2003-11-11 02:57:35 UTC
Reassign issue to owner of selected subcomponent
Comment 5 philipp.lohmann 2003-11-11 10:27:09 UTC
I can't confirm that. If i print a file with multiple copies it simply
contains the statement "/#copies 4 def". For the described behaviour
you have to explicitly set "Create single print jobs" - which is
exactly what it does.

The file psprint/source/printergfx/printjob.cxx by no means
"hardwires" one copy but sets exactly the number of copies specified
in the print job.

This leaves the collation issue which as you say is currently not read
from the PPD file; this of course should be changed. As a workaround
for the meantime you can turn off the "Create single print jobs" in
Tools->Options->Text document->Print and leave the collate checkbox in
the print dialogue unchecked; this produces a file where the copying
is done via PostScripts "/#copies" and all pages are repeated only
once - which should be good for the printer's collation mechanism if
the spooler has it activated.
Comment 6 philipp.lohmann 2003-11-11 10:27:30 UTC
Comment 7 philipp.lohmann 2003-11-11 10:27:41 UTC
Comment 8 opoplawski 2003-11-13 21:48:23 UTC
The following appears to be related, so I'd like to add the following
feature request.  We have a Sharp AR-405 copier/printer that I'd like
to be able to use to print collated and stapled ouput.  With the
windows driver you need to select the 2TrayFinisher output tray and
then you can select Staple.  However, the printer admin tool in OO
does not present me with any options for "Output Tray Options" or
"Staple" after importing the PPD file.
Comment 9 philipp.lohmann 2003-11-14 09:30:53 UTC
You would find them on the device page of the property dialogue; i can
only speculate without the specific PPD file, but usually there are
options to say "a stapler is installed" and if you set that to true
you can access the options concerned.
Comment 10 opoplawski 2003-11-14 18:53:17 UTC
Created attachment 11269 [details]
The Sharp PPD file
Comment 11 opoplawski 2003-11-14 18:53:45 UTC
That's the issue - the PPD file lists the options, but the OO dialog
does not.  There is and entry called "Staple", but the only options
listed are "No".  Same with "Output Tray Options".
Comment 12 philipp.lohmann 2003-11-17 12:23:06 UTC
The supplied Sharp PPD constrains the staple options if the Option1
1ExitTray is installed - which is the default option for Option1. But
you cannot change Option1 to anything else because the other values
for Option1 are all constrained to OutputBin0 - which is the default
for the OutputBin option. Furthermore all OutputBin options besides
OutputBin0 are constrained to 1ExitTray. This leaves no legal way to
change OutputBin or Option1 to anything but the default values, which
is why spadmin does not allow you to do so.

This PPD file looks as if the builder did not keep in mind that
constraints are reciprocal - that is if a constrains b, b must also
constrain a - but explicitly build the PPD violating the PPD spec. It
probably worked with the application he tested with.

So IMHO in the case of this SHARP file spadmin works as it should, but
the PPD is not standard conforming.
Comment 13 rhstone 2004-01-13 22:56:28 UTC
I have a similar problem, which I believe may fall under this bug.

If I print multiple, collated copies of a document with an odd number of pages
to a printer with a duplexer the printer prints the first page of the second
copy on the back of the last page of the first copy. This continues for the
entire print job, which basically makes the job unusable. I suppose I could
mitigate the issue by putting a hard page break in at the end of the last page
so the job is even-numbered, but it would be awfully nice of OO knew how to
insert a blank page at the end of the document.

Comment 14 christof.pintaske 2004-06-17 17:53:10 UTC
cp: retargeted to Office-Later due to limited ressources
Comment 15 strada 2005-03-18 09:54:13 UTC
I disagree with "On normal printer, it is fine, but brings problem on duplex
printers" in the description because:

- OOo will generate X times (e.g. 1000 times) the instructions for the printers,
resulting in huge data being transmitted to the printer which takes first a lot
of time to transmit and second results in a very long ripping-time (the time the
printer translates the data in his own language before he may print the document).
- this is also a problem on normal printers but especially a problem an bigger
machines (duplex or not) where you print many copies of documents (printing with
- for example: if you are printing a brochure with some pictures you have with
no problem hundreds of MB printing data because of this behaviour

I found also another issue in this direction: 43114

(the problem is still there in 2.0beta)
Comment 16 h.ilter 2005-06-24 13:33:52 UTC
*** Issue 43114 has been marked as a duplicate of this issue. ***
Comment 17 philipp.lohmann 2005-10-04 16:46:58 UTC
*** Issue 55148 has been marked as a duplicate of this issue. ***
Comment 18 philipp.lohmann 2006-01-30 10:35:16 UTC
*** Issue 61312 has been marked as a duplicate of this issue. ***
Comment 19 christian.guenther 2006-03-27 13:00:10 UTC
I can reproduce the bug also with Impress on windows.
I change the OS to all.
Comment 20 caolanm 2007-05-01 15:00:44 UTC
*** Issue 71780 has been marked as a duplicate of this issue. ***
Comment 21 philipp.lohmann 2010-01-28 13:12:34 UTC
hardware collation is now supported (since DE300m70) if the printer driver (or
the PPD on Linux) says the hardware can collate.
Comment 22 philipp.lohmann 2010-01-28 13:12:55 UTC
Comment 23 ubanmidna 2010-10-23 15:30:11 UTC
Created attachment 72497