Apache OpenOffice (AOO) Bugzilla – Issue 70531
Print screen not passing information to printer driver
Last modified: 2013-08-07 14:44:35 UTC
This seems to happen only under these circumstances: 1. Multiple page document (say 5 pages), printed two sides 2. Collated and stapled 3. Multiple copies selected (in my case, 150) 4. Printing to Xerox copier/printers (don't know if it does it with others or not-- no way to test) 5. This problem first appeared (I think) with the release candidate prior to 2.04, and continues in 2.04. Select print from the file menu, it brings up the print screen. "Properties" must be selected to choose options like two sided and collated, but the number of copies is selected in this first screen. The problem is that when you select the number of copies in the first screen, that information is NOT being passed on to the printer driver or the printer. This can be confirmed by going to "Properties" and selecting "Advanced" then checking for the number of copies selected in "paper/output"-- the number entered in the first print screen is NOT passed on to the printer driver. My understanding is that the first print screen is native to OO, and that only the "properties" screen is in the print driver.
Reassigned to HI.
Confirming with OO 2.0.4 on Win XP - on attached "print-count.gif" circled in green is competitor's behavior, where copy count in Print dialog is reflected in driver's dialog. Circled in red is how Writer behaves - number of copies is not relected in driver settings. I am not sure what problems such behavior can cause, because Writer prints requested number of copies anyway, so closing as "Invalid". sciteach, if you know how this can cause problem please reopen.
Created attachment 41077 [details] Screenshot showing differencies in behavior
Confirmed.
HI->PL: Maybe you can add it to prdiscw
kpalagin wrote "I am not sure what problems such behavior can cause, because Writer prints requested number of copies anyway, so closing as "Invalid"." The problem it causes is that under the conditions originally specified, Writer does NOT in fact print the job as requested. It will print the number of copies requested, but will NOT collate and staple the job. If I simply go into the driver dialogue and make one change only-- to fill in there the number of copies wanted-- it will then also collate and staple the job as it should have.
pl->fme: collation is done by writer instead of the printer driver, if i remember correctly; but that's not a really new thing. Could you comment ?
Dear developers, any chance of targeting this issue for 2.3? Thanks a lot.
fme->sciteach: I'm a little bit puzzled. Please set the printer driver options to "one copy". Use *only* the settings in the Writer dialog to specify the number of copies and choose whether you want collation or not. What happens in collation mode and what happens in non-collation mode?
sciteach->fme: OK, I ran some more tests. All of these tests were with a 4 page document, printed both sides, with 5 copies requested. The issue is further confused by the fact that there are three levels of dialogues: If you go file>print you get Writer's basic printer dialogue (few options). I'll refer to this dialogue as the "basic" dialogue. If you then hit the "properties" button you get Writer's more advanced printer dialogue with lots of options-- to avoid confusion, I'll refer to this dialogue as the "properties" dialogue. If you then click on the "advanced" tab, you get another dialogue which I'm told by Xerox is Xerox's printer driver's dialogue-- I'll refer to that as the "driver" dialogue. So: If I select 5 copies in Writer's basic dialogue, and check the collate box in that same dialogue, it prints 5 copies and collates them, but does NOT staple them (since there is no option to choose stapling in this dialogue). This is not a practical solution since there is no stapling, or other needed more advanced options. If I select 5 copies in Writer's basic dialogue, and choose collating and stapling in Writer's properties dialogue, it prints 5 copies but does NOT collate the job, but it does staple them. If I select 5 copies collated in Xerox's driver dialogue, and stapling (which is also collating) in Writer's properties dialogue, then it prints 5 copies and it DOES collate and staple correctly-- the job ends up correctly done ONLY in this case. Neither the number of copies selected in Xerox's driver dialogue, nor collating selected in Xerox's driver dialogue, nor even collating/stapling selected in Writer's properties dialogue are passed forward to Writer's basic dialogue. This is a complex issue, and I hope the above at least makes the symptoms clear.
fme->sciteach: Thank you for your detailed analysis. There's only one Writer dialog, both "properties" and "advanced" are from the printer driver. Collation has been implemented in Writer to have this feature also available for printer drivers which do not support collation (at least I think this is the reason). If you set the Writer dialog to "multiple copies" and "collation", Writer will end up sending the document #copies times to the printer driver, so the printer driver does not know and shall not know anything about collation and multiple copies. So what could be done? Writer could check (I don't know if this is possible) if the printer driver supports multiple copies and collation and pass these values to the printer driver to let the printer driver handle multiple copies and collation. Anyway, even in this case you still would have to set the staple option of the printer driver. Right now you should disable multiple copies and collation in the Writer dialog and set these settings at the printer driver (dialog 2+3). To be honest, I don't think we will change the current behavior in the near future. However, you can collect votes for this issue to make it more visible. I'll change the issue type to "enhancement".
*** Issue 77168 has been marked as a duplicate of this issue. ***
following release status meeting -> target 3.x
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".