Bug 439937 - evince attempts to do N-copies work itself (etc) resulting in N*N copies being printed at least when using CUPS
evince attempts to do N-copies work itself (etc) resulting in N*N copies bein...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: evince (Show other bugs)
5.1
All Linux
high Severity high
: rc
: ---
Assigned To: Marek Kašík
desktop-bugs@redhat.com
:
: 472698 501175 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-31 21:18 EDT by Jonathan Peatfield
Modified: 2013-01-10 08:08 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 08:03:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to 'fix' the copies/collate/reverse behaviour (1.74 KB, patch)
2008-03-31 21:18 EDT, Jonathan Peatfield
no flags Details | Diff

  None (edit)
Description Jonathan Peatfield 2008-03-31 21:18:12 EDT
Description of problem:

When evince is viewing a non-postscript document (e.g. pdf) then when printing
if Copies is selected > 1 then it attempts to do the N-copies work itself, but
gtk+ gnome_print also passes the copies through to cups resulting in N*N copies
being printed.

Version-Release number of selected component (if applicable):

evince-0.6.0-8.el5

How reproducible:

100%

Steps to Reproduce:
1. evince tm.pdf
2. go to print select a printer and set Copies > 1
3. click print
  
Actual results:

 N*N copies printed

Expected results:

 N copies printed

Additional info:

The code in shell/ev-jobs.c tries to handle the copies case along with reverse
and collate - all of which seem to get passed through in the cups control file
anyway.

Obviously reverse+reverse ends up being a no-op and the way it does
copies+collate is *wrong* when the printer has duplex enabled or where n-up is
set > 1 (consider a 3 page document being printed with copies=2, the evince code
tries to send pages 1,2,3,1,2,3 so if duplex is on that will do the wrong thing!).

Since the Copies/Reverse/Collate options do seem to make it through to the cups
server (look at the control file after sending to a disabled but accepting cups
queue) there seems to be no point in evince trying to replicate the spoolers work.

I attach a simple patch which just results in evince sending the pages once each
and in the normal order so that the spooler can handle copies/reverse/collate
itself (though it may *not* do the right thing it has a better chance!)

[ up to cups-1.3.4 there are plenty of bugs in the cups pstops filter too which
is why we use a fairly recent cups rather than the standard el5 version ]

Now oddly enough the bug doesn't appear when sending pages from a postscript
document.  Adding debugging shows that in ev_job_print_run() it still called
ev_job_print_do_page() N times for each page but oddly that still only resulted
in one copy of each page making it out to the print-job.  Possibly this was
another bug masking this one.

There is another place shells/ev-print-job.c idle_print_handler() which also
seems to do N copies work itself but in my limited testing it didn't get called
at all.  Perhaps this code is only used when the gimp_print routines arn't found...

 -- Jon
Comment 1 Jonathan Peatfield 2008-03-31 21:18:12 EDT
Created attachment 299799 [details]
patch to 'fix' the copies/collate/reverse behaviour
Comment 2 Jonathan Peatfield 2008-03-31 21:21:36 EDT
I could attach a simpler patch without my extra comments or debugging if you want...
Comment 3 Richard Monk 2008-09-23 11:41:00 EDT
Just FYI, I rebuilt the 0.8 version in FC7 for RHEL5 (and the gnome-icon-theme that it depends on) and the problem is resolved, so upstream this issue is fixed.
Comment 4 ritz 2008-11-11 13:05:38 EST
upstream patch  - http://svn.gnome.org/viewvc/evince?view=revision&revision=2204

_TEST_ package can be collected from http://people.redhat.com/rkhadgar/work/bz439937/
Comment 5 Jonathan Peatfield 2008-11-11 13:44:22 EST
Well that patch seems to send the job requesting one copy - it having done the duplication.  But that will lead to problems when (say) collation is enabled with duplex.  As I said above:

...
 Obviously reverse+reverse ends up being a no-op and the way it does
 copies+collate is *wrong* when the printer has duplex enabled or where n-up is
 set > 1 (consider a 3 page document being printed with copies=2, the evince code
 tries to send pages 1,2,3,1,2,3 so if duplex is on that will do the wrong
 thing!).

The right place to do the copies/collate/reverse document manipulation is in the print spooler - cups in our case and it can actually do the job far better than an app which doesn't know anything about the printer (e.g. some printers do collation in hardware and don't need the job pages replicating).

I still claim that my original patch above is more useful in general - if cups works.  We have been using a patched evince (with my patch) for quite some time now and it seems to fix the issue and is pretty simple to follow...

 -- Jon
Comment 7 ritz 2008-11-12 08:53:15 EST
additional patches included with the above stated patches. hope this fixes the printing bugs in question

http://svn.gnome.org/viewvc/evince?view=revision&revision=2742
http://svn.gnome.org/viewvc/evince?view=revision&revision=2591


updated _TEST_ package can be collected from
http://people.redhat.com/rkhadgar/work/bz439937/
Comment 8 Jonathan Peatfield 2008-11-12 11:56:32 EST
This seems to be adding more code to replicate the print server functionality into an app - and only for non-postscript documents as far as I can tell.  If it wants to do the job properly then it needs to obtain the PPD for the printer so it knows what features the printer has and check with the rest of the cups setup to know what features the user has turned on/off...

No other app seems to need to go to this much trouble - they mostly just generate the postscript and pass parameters to the cups server to ask it to do all the hard work.

I really don't understand why the evince authors want to do this, but then they don't know what the backend spooler may be so it might not support all the options that cups does or may not work for some combinations (e.g. cups used to have bad behaviour when handling multiple copies etc but they were pretty much sorted out a long time ago - well some time in cups-1.3.x anyway)...

 -- Jon
Comment 9 ritz 2008-11-13 00:54:39 EST
afaik, most applications are moving to GtkPrint backend to allow them to work across different platforms, where cups may not be present. 

-- ritz
Comment 11 RHEL Product and Program Management 2009-03-26 13:06:59 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 12 ritz 2009-04-06 14:39:35 EDT
interesting - 
https://bugzilla.redhat.com/show_bug.cgi?id=477773 , probably related ?
Comment 13 Andrew Case 2009-04-14 16:55:06 EDT
Is there a solution or workaround for this?  Ritz's package seems to be non-existent.
Comment 14 Jonathan Peatfield 2009-04-14 17:05:42 EDT
(In reply to comment #13)
> Is there a solution or workaround for this?  Ritz's package seems to be
> non-existent.  

If you want I can point you at the SRPM/RPMs that we use - but those are based on my patches which just get evince to pass the document as-is and let cups do the replication etc...

We have been using them for over a year with no obvious problems... (at least none that have been reported to me).

 -- Jon
Comment 15 Andrew Case 2009-04-14 17:16:27 EDT
Jon,

That would be great.
Comment 19 Matthew Mosesohn 2009-05-19 15:57:23 EDT
What intent is there in fixing this for 5.4?

There are a variety of rendering issues in the existing evince that bumping to the version in Fedora 10 would fix.
Comment 20 Issue Tracker 2009-05-20 09:03:00 EDT
the patch attached to bz# by Jon is a good start, and the most viable
option, under the given consideration., as in the upstream fix is not
doable ( hhttp://bugzilla.gnome.org/show_bug.cgi?id=557112 ), considering
the version of gtk2.

-- ritz


This event sent from IssueTracker by rkhadgar 
 issue 229314
Comment 21 ritz 2009-05-20 10:06:35 EDT
_TEST_ packages can be downloaded from -
http://people.redhat.com/rkhadgar/work/bz439937/
Comment 23 Christopher Aillon 2009-06-09 09:39:34 EDT
*** Bug 501175 has been marked as a duplicate of this bug. ***
Comment 29 Marek Kašík 2009-07-23 10:04:30 EDT
*** Bug 472698 has been marked as a duplicate of this bug. ***
Comment 30 errata-xmlrpc 2009-09-02 08:03:48 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1404.html

Note You need to log in before you can comment on or make changes to this bug.