Ticket #432 (closed defect: worksforme)
collate by default
| Reported by: | geofft | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | Natty Alpha |
| Component: | printing | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
Apparently when you print multiple copies through the default PDF viewer via CUPS, copies aren't automatically collated?
Also, for bonus points, we should make sure we avoid the failure where multiple double-sided copies of a document with an odd number of pages causes the last page of the first copy to be on the same physical sheet as the first page of the second copy.
Change History
comment:2 in reply to: ↑ description Changed 14 years ago by broder
Replying to geofft:
Also, for bonus points, we should make sure we avoid the failure where multiple double-sided copies of a document with an odd number of pages causes the last page of the first copy to be on the same physical sheet as the first page of the second copy.
This is broken in Jaunty (like I described in the first comment), but it looks like it's been fixed in Karmic.
comment:3 Changed 14 years ago by broder
Oh, also, I tried running lpoptions -p meadow -o Collate=True to default to collating. That didn't cause the Collate box in evince's print dialog to be checked, nor did it magically cause the job to be collated.
comment:4 Changed 14 years ago by jdreed
Ah, I knew we had a ticket for this somewhere. One of the OLCs (tkortz) noticed this behavior on lerman (which defaults to double-sided). She opened a one page PDF in Evince, and printed 4 copies, single sided. She got 2 double-sided copies.
comment:7 Changed 14 years ago by rye
I printed 2 copies of a 5-page document from a cluster machine (running Lucid) to metis; I did not change any settings other than the number of copies. The document successfully printed collated and double-sided and without the "last page of the first copy and first page of the next one are on the same physical sheet" bug.
comment:8 Changed 14 years ago by rye
Printing one-sided (both with "Print to LPR" and selecting from the picklist), however, seems to not collate by default.
comment:9 Changed 13 years ago by jdreed
- Priority changed from normal to low
- Milestone changed from IAP 2011 to Natty Alpha
So, does this work correctly if you check the "Collate" box? If so, I vote for document and move on, and possibly attempt to open an LP bug.
comment:10 Changed 13 years ago by jdreed
- Status changed from new to closed
- Resolution set to worksforme
This appears to work in Lucid with Pharos.
Oh man I love CUPS. And Gtk+. And software in general.
It turns out that if you turn on multiple copies and collation in the Gtk+ print GUI, it does the multiple copies and collations itself, instead of submitting the relevant options to CUPS. This means that if you're printing double-sided, it does strictly the wrong thing (including printing the same page on the front and back if you're not collating).
On the other hand, if I run lpr -P meadow -o page-ranges=1-3 -o sides=two-sided-long-edge -# 2 lec1.pdf, CUPS does exactly the right thing. So Gtk+ is screwing it up.
I have no idea how to make it not do that.