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
Created attachment 299799 [details] patch to 'fix' the copies/collate/reverse behaviour
I could attach a simpler patch without my extra comments or debugging if you want...
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.
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/
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
hmm, thanks for the catch. additional patch would be needed http://svn.gnome.org/viewvc/evince?view=revision&revision=2969 http://svn.gnome.org/viewvc/evince?diff_format=l&view=revision&revision=2699 http://svn.gnome.org/viewvc/evince?diff_format=l&view=revision&revision=2700
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/
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
afaik, most applications are moving to GtkPrint backend to allow them to work across different platforms, where cups may not be present. -- ritz
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 "?".
interesting - https://bugzilla.redhat.com/show_bug.cgi?id=477773 , probably related ?
Is there a solution or workaround for this? Ritz's package seems to be non-existent.
(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
Jon, That would be great.
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.
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
_TEST_ packages can be downloaded from - http://people.redhat.com/rkhadgar/work/bz439937/
*** Bug 501175 has been marked as a duplicate of this bug. ***
*** Bug 472698 has been marked as a duplicate of this bug. ***
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