Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||OOo prints multiple copies of a document incorrectly|
|Status:||CLOSED FIXED||QA Contact:||issues@gsl <issues>|
|Priority:||P3||CC:||cno, issues, jr, kpalagin, orion, pavel, strada, utomo.prawiro|
|Target Milestone:||AOO PleaseHelp|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description pmladek 2003-11-10 11:06:57 UTC
The problem: If you print multiple copies of a document from OpenOffice.org (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 times. 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. Solutions: 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 capability.
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 writer
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 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 copy-machines) - 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