|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | OOo prints multiple copies of a document incorrectly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | gsl | Reporter: | pmladek <pmladek> | ||||
| Component: | code | Assignee: | 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: | --- | ||||||
| Attachments: |
|
||||||
|
Description
pmladek
2003-11-10 11:06:57 UTC
is this only happens with Writer, or also with another applications ? Utomo > hi: For printing I think it is GSL issue It happens with other applications as well. It really seems to be a common printig bug. change to GSL component, because it happens in all printing, not only writer Reassign issue to owner of selected subcomponent 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. confirmed started 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. 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. Created attachment 11269 [details]
The Sharp PPD file
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". 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. 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. cp: retargeted to Office-Later due to limited ressources 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) *** Issue 43114 has been marked as a duplicate of this issue. *** *** Issue 55148 has been marked as a duplicate of this issue. *** *** Issue 61312 has been marked as a duplicate of this issue. *** I can reproduce the bug also with Impress on windows. I change the OS to all. *** Issue 71780 has been marked as a duplicate of this issue. *** hardware collation is now supported (since DE300m70) if the printer driver (or the PPD on Linux) says the hardware can collate. closing Created attachment 72497 |