1) Open a document containing multiple pages
2) In the print dialog, change the number of copies to two or greater.
3) Observe that whether "collate" is checked or unchecked, the printed output is the same. The collate setting is ignored.
I think this is a regression. I do not recall the problem in LO 4.1.x
As a workaround, one can check "create single print jobs for collated output" in the options and that will force collate to work, but this becomes cumbersome when making 100+ multiple copies and sending that many separate jobs to the printer.
*** Bug 78753 has been marked as a duplicate of this bug. ***
Please see Comments #5 & 6 in Bug 78753
This may be "caused" a fix for Bug 41524 introduced in LO 4.2.2
Printing through CUPS with collate disabled, it will only print the 1 copy as if i hadnt changed the number of copies, but with collate enabled and copies set to 2, that works fine.
Test in Linux Mint with 3.6, 4.1, 4.2 and 4.3b.
It's NOT working in 4.3beta1.
Print from LO, get pages 1,1,2,2
Export to PDF and print from acroread, get pages 1,2,1,2
(same printer, same driver)
Note that the wrong behavior occurs with only some drivers. LO works fine with HP printers but not Brother MFCs (see comment #5 in bug 78753). So there must be something about how LO interacts with CUPS which is different than acroread, and is either wrong or correct but tickles a driver bug.
I'll attach a copy of the ppd files for the Brother printer (on which the problem appears) and the HP printer (on which it does not appear).
Created attachment 100189 [details]
/etc/cups/ppd/MFC9340CDW.ppd (Brother; problem appears)
Created attachment 100190 [details]
/etc/cups/ppd/HP_LaserJet_3030_pcl.ppd (on which problem does not appear)
Created attachment 100191 [details]
This is a different ppd file for the Brother printer which the Brother driver installer put on my system. I have no idea whether it is actually used somewhere/somehow, but it is different than the ppd in /etc/cups/ppd/<queuename>
The Brother driver ignores the Collate option when sent a PDF file (as happens with LibO) but *does* honor Collate with Postscript input (as happens with acroread). I figured this out using strace on the two programs.
The same symptoms occur printing equivalent .pdf and .ps files with "lpr '-#' 2 -o Collate=true ..." namely Collate works only with Postscript.
This is clearly not a problem with LibO, so please ignore this sub-thread with my apologies.
Unfortunately everyone with Brother printers (modern ones, anyway) probably can't print collated copies directly from LibO.
> Unfortunately everyone with Brother printers (modern ones, anyway) probably
> can't print collated copies directly from LibO.
For me, though, this doesn't explain why collate worked on LO 4.1 but fails on 4.2 and higher. (I'm using a Brother 5370DW with the driver from the Brother website.) I did not change my printer or driver, only the LO version.
> The Brother driver ignores the Collate option when sent a PDF file (as
> happens with LibO) but *does* honor Collate with Postscript input (as
> happens with acroread). I figured this out using strace on the two programs.
This may well be correct, but I do not have LO sending a PDF file to the printer (changed that setting to Postscript a long time ago because of other problems).
Ah, I didn't know there was such an option. That could save the day.
bach_leipzig, where is the option you used to make LO send Postscript to pinters?
(In reply to comment #12)
> Ah, I didn't know there was such an option. That could save the day.
> bach_leipzig, where is the option you used to make LO send Postscript to
From the print dialog, press the "Properties" button, then select the "Device" tab. Under "Printer Language Type" change it to Postscript. I discovered this when I needed a workaround for a font kerning bug, but it hasn't helped me with the collating problem.
Well i did some testing on Windows 7 with a document which had 2 pages, each labelled with their page number and here are the results for collation being off and number of copies set to 2.
PrimoPDF - printed 1, 2
Foxit PDF Printer - printed 1, 1, 2, 2
Microsoft XPS - printed 1, 1, 2, 2
I noticed that PrimoPDF's advanced settings has a collated setting in it, which makes sense why it was ignoring LibO's collated setting. So i personal dont feel this is a bug from LibO's side and is just a problem with Brother printers.
Yes, it is a problem with Brother's drivers, not LibO. My apologies for the false alarm.
No more posts on that topic are necessary.
Migrating Whiteboard tags to Keywords: (needAdvice)
'needsConfirmationAdvice' is only used for unconfirmed bugs. Removing it from this bug.