> if the PPD for the printer contains "Collate=True" and if it doesn't then > Collate is handled > as fall-back by LO itself so you get multiple jobs.
Just to clarify: The reason this is not a good idea is that CUPS already handles this case wotj a better & smarter solution. The whole thing appears as a single job in the print queue which can be canceled, etc. rather than as many independent jobs. For example, the CUPS foomatic Postscript driver implements the '#<numcopies>' lpr option by replicating the document's page descriptions and sending a *single* Postscript file to the printer containing all the pages. So if the document has 3 pages, and you ask for 10 copies, then a single job is sent to the printer containing 30 pages, and the job can be paused or canceled in CUPS or cancelled by pressing a button on the printer. CUPS+gutenprint for HP printers does a similar thing but sends a PCL file instead of Postscript. (This is on Ubuntu linux. If the print server on Windows can't handle this sort of thing then LO should do something similar (*not* queuing multiple jobs) on Windows. But on Linux it doesn't need to do anything at all, just pass the '#<numcopies' argument to the lpr command or equivalent) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1025839 Title: Printing multiple copies submits multiple separate jobs (should submit one job) Status in LibreOffice Productivity Suite: In Progress Status in “libreoffice” package in Ubuntu: Confirmed Bug description: In the print dialog, if "Number of Copies" is set to 50 then 50 separate, independent print jobs are spooled. It should submit a single print job, specifying 50 copies. This will allow the printer to do the replication if it can (all Postscript printers can). This is important because: 1) Submitting a separate jobs for each copy causes the page(s) to be rendered again and again, with a drastic reduction in through-put. This is CRUCIAL if the pages contain complex graphics or images which take a long time to render or transmit to the printer: A one-minute delay for the first of 50 copies is okay, but 1 minute for *each* of 50 copies is intolerable. 2) If the print job was a mistake, it is virtually impossible to stop the printer. Pressing the cancel button on the printer cancels just one copy, but after a little while the next one starts printing... 3) It is very inconvenient to cancel the job in CUPS, with 50 separate jobs, without affecting other unrelated jobs in the queue (you can cancel all jobs in the queue at once, or one at a time). Note that CUPS has always supported a "number of copies" option at the command-line level. For example lpr '-#50' file.pdf prints 50 copies of the file, rendering it once only. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: libreoffice-writer 1:3.4.4-0ubuntu1.2 ProcVersionSignature: Ubuntu 3.0.0-22.36-generic 3.0.33 Uname: Linux 3.0.0-22-generic x86_64 ApportVersion: 1.23-0ubuntu4 Architecture: amd64 Date: Tue Jul 17 11:49:58 2012 InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012) ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: libreoffice UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1025839/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
