GNOME Bugzilla – Bug 679400
GtkPrintOperation should allow use_full_page when manual_number_up > 1
Last modified: 2018-02-10 03:40:53 UTC
If the user specifies more than one page per side then currently it always gives the default page margin around the multi-page composition. If the application has set 'use_full_page' then this margin should not be enforced, and the multi-page composition should be allowed to use the full page area. This is particular relevant when a user is printing to a file, e.g. I typically print-to-file in a program like 'evince' to compose myself a set of A6 flyers tiled 4-up on an A4 sheet. With the current margin enforcement I can never quite get exactly what I want in this way. Allowing true full page usage would solve this problem.
Created attachment 218017 [details] [review] Proposed patch to fix the problem This patch ignores the page margins in the multi-page composition code if use_full_page is set. It is then up to the application (or for the application to give the option to the user) to determine if margins are required around the edge of the composition.
You mean, if my document is set up to have 3 cm margins all around, and I select N-up printing, then the pages are shrunk and tiled to fit in a page with a 3 cm margin? If so, then that doesn't make sense, and your patch is doing things in the right direction. One detail - what happens when the shrunken/tiled page would print things outside the printer's usable area? Does GTK+ have a concept of this?
Frederico: >You mean, if my document is set up to have 3 cm margins all around, and I >select N-up printing, then the pages are shrunk and tiled to fit in a page with >a 3 cm margin? No, that is not what happens. Currently in N-up the pages are shrunk/tiled to fit in a page with margins hard-coded by some file in the gtk source code (I forget the values, but the top & bottom values are different so you get an uneven margin). If your doc is typeset to have pages with a margin (say your 3cm), then these margins will be shrunk along with the page contents and appear in the tiling. I.e. the eventual 'effective' margin (distance between paper edge and actual contents of a tiled-page) is the hard-coded value above PLUS the shrunk margin of the original document. My patch gives the possibility to remove the hard-coded margin altogether for when the app requests 'use full page area'. The 'effective' margin is then just the shrunk margin of the original document.
Yes, this makes perfect sense! The patch looks good to me. Marek? :)
Hi, the original idea was to make the preview produce the same result as if you print to a CUPS printer. But CUPS printers add some margins (at least when we are printing through GtkPrintOperation). I'll check tomorrow whether CUPS behave here correctly or not. Regards Marek
Hi, the problem with the patch is that if the application set the use_full_page to true then it knows that it needs to solve the margins itself. So it will draw the page inside printable area of the page if the user sets e.g. fit to printable area in evince. But if we allow it to print to the whole page then the real margins will be half of the size for 4 pages per sheet. The application would draw something into places where it shouldn't in this case. There is also the second problem that preview wouldn't produce the same results as printing to a CUPS printer. But there is a solution to the problem you've described. You can create a custom page size with no margins and print on it. Unfortunately this doesn't work now, but I will fix this soon (the custom page setups listed there doesn't use specified margins but the default ones (a GtkPaperSize vs. GtkPageSetup problem)). I would prefer to not commit the patch. I think that margins for number-up printing should be driven by gtk. Regards Marek
(In reply to comment #6) > Unfortunately this doesn't work now, but I will fix this soon (the custom page > setups listed there doesn't use specified margins but the default ones (a > GtkPaperSize vs. GtkPageSetup problem)). It works but you have to select right custom paper size in the combo box. The custom paper sizes are listed twice for file print backend now and only the second ones have correct margins (see bug #683474).
Marek OK - I see your logic, and that a custom paper size with zero margins will get me what I want. But as an improvement to Gtk printing, what if I tried a new patch where the Gtk N-up code fetches the actual printer margins (which is what evince does for its 'shrink to fit' option)? That would enable the N-up code to tile into the actual imageable area for the selected printer - and should enable print-preview and print-actual to give the same results. Note though, on this question of print-preview vs print-actual I figure you are always going to have the potential for the two outputs to come out different. Thats because printers like mine (an epson, that uses cups+gutenprint) have an option to shrink/crop/expand in the Advanced options tab, i.e. it is a ppd option built into the backend filter itself (plus the ppd 'borderless' option). Print-preview can't predict what that option is going to do (or at least I assume such prediction is not possible), so the actual printed output may well differ. Having said that, I do accept that we should match as much as we can, at least for the things we can predict.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.