If I print a document in 100 copies, LO 3.4.3 sends to the print queue 100 print jobs, instead of sending a single jobs that prints the 100 pages. That results in a saturation of the print queue. LO 3.3 behaved differently.
my printer is a Ricoh Aficio MP-2550 (NRG-MP-2550), the sistem uses it with a socket://192.168.0.44:9100 uri, and the driver is CUPS+Gutemprint v2.5.6
I have the same problem. I'm running LibreOffice (version directly from LibreOffice) 3.4.4 on Ubuntu 11.10. I tried printing 75 copies of a single sheet with significant graphics (large file size) on a black and white Konica-Minolta PagePro 1400w laser printer. I had no idea that LibreOffice would be sending 75 individual print jobs to the printer instead of 1 print job with 75 copies. It crashed the printer, and also the driver after several copies. Then there was the horrendous mess of getting all of the unprinted jobs deleted. I was able to use my inkjet (HP OfficeJet Pro 8000) to finish the printing after the laser crashed. Once again individual print jobs were sent for each copy, but the printer did not crash. Once everything was printed, I had about 10 minutes of icons coming on the screen saying printing started and printing completed when the printing was all done. The icons were playing catchup with all of the print jobs. I've tried to research this. The only way I've found that you can print a large number of copies is to export the page to pdf, and then print the pdf. Programs other than LibreOffice (GEdit, Document Viewer) send 1 job to the printer with multiple copies. This problem did not exist in OpenOffice a year ago with whatever was the current version of openoffice on Ubuntu 10.10 back then when I printed the same job on the same laser printer.
I have both 3.3.4 and 3.4.4 installed so I can test in parallel. 3.3.4 prints properly (1 job, multiple pages) as long as the 'Collate' option is checked in the print dialog. Unchecking 'Collate' and printing results in multiple print jobs as expected. So as to not waste ink, just test by printing to a cups-pdf printer. In 3.4.4 it's as if the 'Collate' feature doesn't exist. 3.4.4 prints multiple print jobs whether the 'Collate' option is checked or not. Ubuntu 10.10 linux: versions are directly from LO. LibreOffice 3.4.4 OOO340m1 (Build:402) LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.4.1
Same issue in 3.5 beta 1: LOdev 3.5.0 Build ID: 7362ca8-b5a8e65-af86909-d471f98-61464c4
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Issue still present on LO 3.5 RC3 on Ubuntu 11.10
I manage about 1000 computers that this is causing problems on - the huge number of print jobs created when a user prints multiple copies is slowing down the printers and causing problems with print release software that lets users confirm and pay for print jobs before they are printed. I realize that most home users might not notice the difference between one multi-copy job and several individual jobs, but in larger environments it is a huge problem. I wonder if this is the same as bug 46904 which seems to be attracting a little more attention: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=46904 Any advice on how to patch this or work around it without user intervention would be greatly appreciated. Currently it looks like the only solution is to go back to version 3.3.4.1 I just tested this with version 3.3.4.1 and the problem does not occur. Testing with 3.4.0 and 3.5.1 showed the bug. The base system is Ubuntu 10.04 and the problem occurs with .debs grabbed directly from libreoffice. Diffing the source from 3.3.4.1 vs. 3.4.0 shows libreoffice-3.4.0.1/vcl/unx/source/printer/cupsmgr.cxx had a few changes that look relevant, but I'm in way over my head here: bool bUsePDF = false; cups_dest_t* pDest = ((cups_dest_t*)m_pDests); const char* pOpt = m_pCUPSWrapper->cupsGetOption( "printer-info", pDest->num_options, pDest->options ); if( pOpt ) { m_bUseIncludeFeature = true; bUsePDF = true; if( m_aGlobalDefaults.m_nPSLevel == 0 && m_aGlobalDefaults.m_nPDFDevice == 0 ) m_aGlobalDefaults.m_nPDFDevice = 1; } ... if( rJob.m_nPDFDevice > 0 && rJob.m_nCopies > 1 ) { rtl::OString aVal( rtl::OString::valueOf( sal_Int32( rJob.m_nCopies ) ) ); rNumOptions = m_pCUPSWrapper->cupsAddOption( "copies", aVal.getStr(), rNumOptions, (cups_option_t**)rOptions ); } if( ! bBanner ) { rNumOptions = m_pCUPSWrapper->cupsAddOption( "job-sheets", "none", rNumOptions, (cups_option_t**)rOptions ); } }
This is claimed to be working in 3.3 and broken in 3.4 -> regression
This seems to be a feature, not a bug. LibreOffice queries the printer if it is capable of collating jobs and acts accordingly (read: It is reported to LibreOffice that the printer can handle collation). see: http://opengrok.libreoffice.org/s?refs=PRINTER_CAPABILITIES_COLLATECOPIES&project=core
In my system libreoffice produce multiple print jobs, but if I first create a pdf and then print the pdf in multiple copies, then one print job is produced. This makes me think the problem isn't in the printer or in its capacities, but in something libreoffice doesn't handle while evince does.
Also CC'ing dtardon here, as it is possibly related to the same changes that caused bug 46904. @dtardon: Care to have a look?
(In reply to comment #11) > Also CC'ing dtardon here, as it is possibly related to the same changes that > caused bug 46904. It was reported for 3.4.3, so unfortunately no :-( > @dtardon: Care to have a look? Sure, why not...
Not much more to add, except it is still present in 4.0.4.2 release. I use LibreOffice cross platform ,this bug manefests only on Linux machines. Tested with 4.0.4.2 on Mint Linux 14 & 15 on Cinnanamon, XFCE & MATE 1.2. Only work around is to export document as PDF and use your prefered document viewer to manage the print job. This is a serious bug for anyone using LibreOffice for large multiple copy print jobs on a regular basis.
*** Bug 51111 has been marked as a duplicate of this bug. ***
To me this means that I need to give multiple print command when doing more copies. Depending on selection/direction or such. Luckily I do not print much :) @david: still interested to take a look? This is set as enhancement. But since 3.3 worked fine, this is a simple bug?
this is apparently a feature (as already mentinoed by Bjoern comment #9) that was introduced in OOo 3.3, CWS "pdfprint". relevant code in PspSalInfoPrinter::GetCapabilities: const PPDKey* pKey = aData.m_pParser ? aData.m_pParser->getKey( OUString("Collate") ) : NULL; const PPDValue* pVal = pKey ? pKey->getValue(OUString("True")) : NULL; so we check 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. can people affected by this please check if the CUPS PPD file for their printer contains a "Collate" line? not knowing much about PPDs i'm wondering if "True" is the only value we need to check for, and whether assuming the printer can't do it is an appropriate default if "Collate" is missing.
This issue is still present with Ubuntu 13.10 and LibreOffice 4.1.5.3. From reading the comments above, some are saying this is a feature. I don't think so, and the collate should not be an issue. Single page dosuments have the same thing happen. For 10 copies of a single page the printer gets 10 print jobs of 1 page each and not 1 print job of 10 copies. This has happened on my two office printers here in the last week when I'm in a hurry and forget to make a pdf before printing so I can print the documents as PDF files. These printers are a Samsung ML-2955ND and an Epson WorkForce WP-4530.
Normally an app does not need to care of Collate supported by the printer or not. It should simply send one copy of the job and the IPP attributes for the number of copies and for collate on/off. Then there is only one CUPS job and CUPS handles hopw it gets printed, especially whether the printer does hardware copies/collate and if not sending data repeatedly within this one job. An app should never send more than one job to CUPS when the user has clicked "Print" once. This is a bug. Page management (copies, collate, even/odd pages, selected pages, mirrored print, N-up, ...) is handled by CUPS, so please let the desktop apps send one copy of the full document along with the appropriate IPP attributes to control page management. CUPS does the rest then, in the same way as for the other apps. Only exception couls be selected pages here, to not send 100 pages to CUPS if the user only wants 1 page.
have implemented this now, CUPS printers are now assumed to always support collation, and for PDF based printers we call cupsAddOption("collate", ...) while PS based legacy printers still get their weird PPD stuff. this has been tested on 1 HP printer so far, but that one probably worked before already so it's not very interesting :) oddly we have a "Create single print jobs for collated output" checkbox buried in the print dialog that can still enable the objectionable behaviour, which no doubt some user has cried loudly for many years ago... i wonder when support for PS CUPS printing could be removed, currently we build for a RHEL5-era Linux baseline...
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c76cd71fe9bdefaef3f33f8ca193c32e3ab112ed fdo#41524: CUPS printing: use "collate" option when PDF is available The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=138f41fd408b120d52e3d6c185940ace065512af&h=libreoffice-4-2 fdo#41524: CUPS printing: use "collate" option when PDF is available It will be available in LibreOffice 4.2.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b15c48ed0e3db69066ca3b2b40acfb61508dd369&h=libreoffice-4-2-2 fdo#41524: CUPS printing: use "collate" option when PDF is available It will be available already in LibreOffice 4.2.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tested and very pleased to say the problem is fixed in our environment. Thanks, been waiting a long time for this one!