Bug 107416 - Printing multiple copies results in multiple print jobs
Summary: Printing multiple copies results in multiple print jobs
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta1
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0 target:6.1.5 target:6.2....
Keywords: bibisected, bisected, regression
: 117914 118152 (view as bug list)
Depends on:
Blocks: Print-Dialog
  Show dependency treegraph
 
Reported: 2017-04-25 14:09 UTC by Laurent BP
Modified: 2020-03-24 14:36 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent BP 2017-04-25 14:09:18 UTC
Description:
When printing multiple copies, same number of jobs is created. On a network printer, it requires to release each job which can be complicated if the number of copies is high.

Steps to Reproduce:
1. Ctrl+P with any document type
2. Increase number of copies in dialog, OK
3. Check your printer queue

Actual Results:  
There are as many as jobs than copies in the list.

Expected Results:
Only one job for any copies of the same document.


Reproducible: Always

User Profile Reset: Yes. Same behavior

Additional Info:
There is no pb with LibO 5.2. Set as regression.

Not reproduce with: Version: 5.3.0.0.alpha0+
Build ID: 42062d99f171196778685e655e4edafd33ac159f
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-19_00:28:04
Locale: fr-FR (fr_FR); Calc: CL

Workaround: in Print dialog, open Properties of the printer and change the number of copies. Let 1 copy in LibO dialog.

It can be a serious pb if your printer add a page before each job. When you launch several printing on a network printer with multiple copies, it is difficult to find the right job in the queue.


User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Laurent BP 2017-04-25 15:29:25 UTC
I can NOT reproduce with:
- Version: 5.3.0.0.alpha1 (x64)
Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f
Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: CL

I can reproduce with:
- Version: 5.3.0.3 (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR); Calc: CL
- Version: 5.3.0.1 (x64)
Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9
Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR); Calc: CL
- Version: 5.3.0.0.beta2 (x64)
Build ID: a7e30712ad6d8bc9286007b37aa581983e0caba3
Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR); Calc: CL
- Version: 5.3.0.0.beta1 (x64)
Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; Layout Engine: new; 
Locale : fr-FR (fr_FR); Calc: CL

So regression was introduced between alpha1 and beta1.
Comment 2 gmusgrave 2017-05-06 16:30:30 UTC
I have the same issue. I was about to submit a bug report, when I saw this one. 

I'm using V5.3.2.2

I discovered this when I tried to print 75 copies of a two-page document, saw a problem with one page, and tried to cancel the print job. There were 75 separate print jobs to cancel!

This is a problem for me for two reasons:

1. If you need to cancel the print job (more likely with multiple copies), you must cancel every individual job! This is onerous and difficult.

2. My HP Laserjet process each job for a few seconds before starting to spit out pages. Normally, when an application sends the job once and tells the printer to print x copies, this happens only at the start, and then all subsequent copies fly out at full speed. Since the application is creating separate print jobs for each copy, this printer processing overhead is applied to every copy, and the total print time is severely impacted.
Comment 3 Laurent BP 2017-05-06 16:44:50 UTC
Thanks for confirmation. Set to NEW
Comment 4 Buovjaga 2017-09-19 13:09:23 UTC
(In reply to Laurent BP from comment #1)
> I can NOT reproduce with:
> - Version: 5.3.0.0.alpha1 (x64)
> Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f
> Threads CPU : 2; Version de l'OS :Windows 6.1; UI Render : par défaut; 
> Locale : fr-FR (fr_FR); Calc: CL

Laurent: could you try bibisecting it on Windows? https://wiki.documentfoundation.org/QA/Bibisect/Windows

Based on your testing, it seems you should clone 5.4 repo:
git clone git://gerrit.libreoffice.org/bibisect-win32-5.4

as it is described: "libreoffice-5-3-branch-point to libreoffice-5-4-branch-point and then libreoffice-5-4"
Comment 5 Aron Budea 2017-09-19 13:33:38 UTC
If it can be reproduced with a PDF printer (eg. FoxIt Reader's), I can try bibisecting this.
Comment 6 Aron Budea 2017-09-20 20:36:18 UTC
A problem with bibisecting is that the first commit from the bibisect-win32-5.3 bibisect repo already prints with multiple jobs:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=5b168b3fa568e48e795234dc5fa454bf24c9805e

However, the preceding commit from bibisect-win32-5.2 bibisect repo only prints with a single job:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=75f37680e1b4ba7f729bee45438a0dfcc1ce18c8

The question is, what might be going on...?
Comment 7 Aron Budea 2017-09-20 20:41:48 UTC
And while the results with the bibisect repos don't agree with Laurent's observation in comment 1, strangely I can't reproduce with 5.3.0.3, which doesn't agree with either:

Version: 5.3.0.3
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 16; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: hu-HU (hu_HU); Calc: group
Comment 8 Laurent BP 2017-09-21 09:36:47 UTC
(In reply to Aron Budea from comment #5)
> If it can be reproduced with a PDF printer (eg. FoxIt Reader's), I can try
> bibisecting this.

Yes I can reproduce with PDFCreator printer on Windows: asking 20 copies result in 20 files in LibO 5.3.6.1, whereas with LibO 5.2.7 it produces only 1 file.

However, be careful to start with a new profile for each test, because I noticed that using LibO 5.2.7 with my actual profile (used with LibO 5.3.6.1) makes the bug active.
Comment 9 Laurent BP 2017-09-21 12:03:30 UTC
From my tests, I suggest that default profile is responsible of the bug. My procedure:
1. Launch LibO Version: 5.3.0.0.alpha1 (x64) with a new profile
2. Print multiple copies: NO bug
3. Launch LibO Version: 5.3.0.0.beta1 (x64) with a new profile
4. Print multiple copies: bug is present
5. Stop LibO 530.0b1, and modify its bootstrap.ini file to use profile of LibO530.0a1
6. Print multiple copies: NO bug
Comment 10 Serge Smeesters 2017-09-22 10:07:55 UTC
I've got this bug also here with GNU/Linux!

System: Mint 18.2 MATE 64 bits

Printer: Ricoh MPC 4503

LibreOffice Build ID: 1:5.4.1~rc2-0ubuntu0.16.04.1~lo0
Comment 11 Aron Budea 2017-09-22 23:45:26 UTC
Good hint, Laurent. Bibisected to the commit referenced below using repo bibisect-win32-5.3.
Adding Cc: to Gabor Kelemen for fun :) (the commit is just a setting change, I'd assume the issue is in the code rather).

https://cgit.freedesktop.org/libreoffice/core/commit/?id=37c3e57c788fb5ad931126ea233093d87ac3dbc3
author		Gabor Kelemen <kelemeng@ubuntu.com>	2016-11-11 12:46:54 (GMT)
committer	jan iversen <jani@documentfoundation.org>	2016-11-14 10:14:29 (GMT)

"tdf#103703 Turn on single print jobs for collated prints by default

This way when printing documents with odd number of pages
and collated printing is selected the first page of the
second copy is not printed to the empty last page of the firs copy."

These values are written to the profile after doing a test print with an empty profile (see the difference in CollateSingleJobs):

GOOD
<item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['PrintDialog']"><prop oor:name="Collate" oor:op="fuse" oor:type="xs:string"><value>true</value></prop></item>
<item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['PrintDialog']"><prop oor:name="CollateBox" oor:op="fuse" oor:type="xs:string"><value>Default</value></prop></item>
<item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['PrintDialog']"><prop oor:name="CollateSingleJobs" oor:op="fuse" oor:type="xs:string"><value>false</value></prop></item>

BAD
<item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['PrintDialog']"><prop oor:name="Collate" oor:op="fuse" oor:type="xs:string"><value>true</value></prop></item>
<item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['PrintDialog']"><prop oor:name="CollateBox" oor:op="fuse" oor:type="xs:string"><value>Default</value></prop></item>
<item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['PrintDialog']"><prop oor:name="CollateSingleJobs" oor:op="fuse" oor:type="xs:string"><value>true</value></prop></item>
Comment 12 Laurent BP 2017-09-23 16:54:59 UTC
So it is not a bug, it is a feature!
Simply uncheck option in Print dialog:
File > Print > Options: "Create single print jobs for collated output"
and you get the previous behavior.

However, from my point of view, this option does the opposite of what it should. True and False should be inverted. Or my English is too poor?
Comment 13 Gabor Kelemen 2017-09-24 08:46:20 UTC
(In reply to Laurent BP from comment #12)
> So it is not a bug, it is a feature!
> Simply uncheck option in Print dialog:
> File > Print > Options: "Create single print jobs for collated output"
> and you get the previous behavior.

Yes, but then if you want to print multiple copies of a document with an odd number of pages then you would get the last page of one copy and the first page of the next one on the same piece of paper, which is kinda annoying.

This is what bug #103703 was about. Changing the default works that around, but not without some side effects.

Probably we should reopen that one and change the software for good to insert a blank page after the last page when printing multiple copies of a document with odd number of pages. Then my workaround can be undone.
Comment 14 Laurent BP 2017-09-24 08:55:29 UTC
(In reply to Gabor Kelemen from comment #13)
> Probably we should reopen that one and change the software for good to
> insert a blank page after the last page when printing multiple copies of a
> document with odd number of pages. Then my workaround can be undone.

+1

However, this option does the opposite of what it says. I opened bug 112607 about this different problem. Please confirm it, if you agree.
Comment 15 Timur 2018-04-19 09:06:36 UTC
Per Comment 12 and on I'll close as NotaBug.
If I'm wrong, please explain what this bug is about.
Comment 16 Buovjaga 2018-06-22 10:04:28 UTC
*** Bug 118152 has been marked as a duplicate of this bug. ***
Comment 17 Buovjaga 2018-06-22 10:04:35 UTC
*** Bug 117914 has been marked as a duplicate of this bug. ***
Comment 18 Gabor Kelemen 2018-11-07 07:45:40 UTC
Let me reopen this. 
One of our users complained about this situation, so I had to dig in :).

So the original problem was bug #89708, and bug #103703 is a duplicate for that. 
Since #89708 is fixed properly, there is no need to keep the workaround committed for #103703

I'll submit a reverting patch.
Comment 19 Commit Notification 2019-01-10 17:25:55 UTC
Gabor Kelemen committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/2117257eafac507b6af0be86ae62261fd192089a%5E%21

tdf#107416 Revert "tdf#103703 Turn on single print jobs for collated prints"

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2019-01-11 12:52:48 UTC
Gabor Kelemen committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

https://git.libreoffice.org/core/+/d8d148c96d7cdd96948240ac30b3aeacfb5aa7ca%5E%21

tdf#107416 Revert "tdf#103703 Turn on single print jobs for collated prints"

It will be available in 6.1.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Commit Notification 2019-01-14 09:26:38 UTC
Gabor Kelemen committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/3b10c732a83122198886ec16986110d5ad668a1e%5E%21

tdf#107416 Revert "tdf#103703 Turn on single print jobs for collated prints"

It will be available in 6.2.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Commit Notification 2019-01-21 17:14:50 UTC
Gabor Kelemen committed a patch related to this issue.
It has been pushed to "libreoffice-6-2-0":

https://git.libreoffice.org/core/+/72d6916a05e7862e6b7ac033f8e74feed931e3bc%5E%21

tdf#107416 Revert "tdf#103703 Turn on single print jobs for collated prints"

It will be available in 6.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 23 kathleenisbell511 2019-07-25 10:56:00 UTC Comment hidden (spam)
Comment 24 Sharon 2020-03-24 14:24:30 UTC Comment hidden (spam)