GNOME Bugzilla – Bug 166564
printing doesn't respect the layout setting in gnomeprint
Last modified: 2009-04-13 15:13:22 UTC
When you print a pdf document with evince and select layout "4 pages on 1" you still get normal "1 page on 1" output. To reproduce: open a dpf document (haven't tested to see if this is a general problem), print. In the print dialog change the layout setting. Note: This problem also exists in gpdf (#125897, #142370).
I've written a patch for libgnomeprint to fix this - at least when using the CUPS backend. http://mail.gnome.org/archives/gnome-print-list/2005-February/msg00005.html
Could you attach that patch to this bug, just to keep everything in the same place. Thanks.
Created attachment 38068 [details] [review] libgnomeprint patch to support multipage print with CUPS
Adding the PATCH keyword, all the work in Evince is going into the new threading system right now so I suspect printing patches will sit a bit longer :-( Sorry!
Martin, if you could have a look to this, it would be great.
This is a libgnomeprint bug, right? Reassigning.
I'm not sure it is libgnomeprints fault. When I first reported the bug (with gpdf) I also assumed it was libgnomeprint, but then it was reassigned to gpdf since it worked for other programs like gedit. I was told it was caused of the fact that gpdf had a special handling of gnomeprint, like drawing direct on the prinitng canvas, that was the cause of it. I might understood things wrong, so don't take my word for it.
reassigning to evince.
Created attachment 46152 [details] [review] libgnomeprint patch for multipage, number of copies and duplex/tumple support I've updated my patch against libgnomeprint. Now it should correctly forward multipage, number of copies, and duplex / tumble to cups. I still think it's a libgnomeprint issue as all programs using input_file are affected. Bug 172928 is basically about the same issue.
Created attachment 46154 [details] [review] typo fix
Created attachment 46202 [details] [review] alternative more generic libgnomeprint patch As there were still some problems left even with my patch applied, I've written an alternative, more generic version. It's now possible to print to generic postscript and to create a pdf document while retaining the paper and layout settings (e.g. create a pdf/ps from an existing pdf/ps with 2 pages per sheet) and lpr and papi transport should work, too. The disadvantage is that it only works as desired with pstops (cups filter), ps2pdf (ghostscript), and a generic postscript ppd (foomatic). A generic ppd may be added to libgnomeprint itself, the other two dependencies are probably a non-issue for most GNU/Linux distributions but maybe problematic for others, I don't know.
Reassigning to gnome-print since this is a gnome-print patch.
*** Bug 172928 has been marked as a duplicate of this bug. ***
Comment on attachment 46202 [details] [review] alternative more generic libgnomeprint patch This is entirely too generic. I don't like the notion of using CUPS outside of the cups module.
Comment on attachment 46154 [details] [review] typo fix Reasonable but the n-up support looks fishy. Talk to lutz.
Comment on attachment 46154 [details] [review] typo fix Reasonable but the n-up support looks fishy. Talk to lutz he knows a fair amount about this.
N-up printing works with this patch, but the margins are all wrong then (when printing on A4 paper). Printing 1-up uses correct margins for A4. When I just print with lpr (I have nup=2 in .lpoptions) it prints correctly. Maybe the paper settings are not correctly forwarded?
Just for the record: gnome_print_job_set_file passes data directly to the printer (transport), leaving out the standard API (lineto, moveto), the creation of meta data and the conversion of this meta data into other formats like PDF/PS (driver). Both ggv and gpdf use this function. The UI hides all that complexity. The user does not see that: - "Range" is related to meta data - "Copies" is related to transports/meta data (if not supp. by transp.) - "Duplex" is related to the driver - "Paper size" is related to the driver - "Layout" (n-up) is related to meta data In my opinion, we should, in a first step, fix the UI to make all options insensitive that cannot be honoured when using gnome_print_job_set_file (i.e. everything related to meta data and drivers). In a second step, we should add the n-up support just like the support for "Copies": Using GNOME_PRINT_KEY_[NUP,COLLATED_COPIES]_IN_HW.
*** Bug 305674 has been marked as a duplicate of this bug. ***
I understand that it's somewhat more complicated to fix this in a clean way but the problem is there now for end users of gpdf, evince, and now epiphany, too. AFAIK the long-term solution is cairo-based gtk print anyway, so we shouldn't wait until someone has time to really cleanup everything around gnome_print_job_set_file - which libgnomeprint wasn't designed for originally - but commit something like in #10 now, i.e. before code freeze of 2.11. It works AFAICT and there shouldn't be any situations it would harm, so please reconsider applying the patch.
*** Bug 311347 has been marked as a duplicate of this bug. ***
Are there plans to fix this issue for Gnome 2.14?
some news on this bug?
libgnomeprint is basicly unmaintained and this patch has missed another release cycle.
hm curious that printing in gnome is unmaintained. are the enterprise linux distributors fixing it theirselfes or has nobody yet noticed this issue? ;)
Mentioned in https://launchpad.net/products/gnome-print/+bug/3667 as well.
*** Bug 315526 has been marked as a duplicate of this bug. ***
If this is still an issue it should be reported against gtk+ printing.
As far as I know, this works fine with GTK+ printing now.
You are right, this is working now... I'm just bad at following up my bugs.