GNOME Bugzilla – Bug 110222
printing options that'll make printing in gnome the ultimate experience ;)
Last modified: 2006-08-15 10:21:52 UTC
printing options 1. - odd, even pages only via checkbox or radio button :) 2. - reverse order very useful when you want to print doublesided, you just flip the papers in the printer select even/odd only and hit print. :) 3. - arbitrary eg. 2-5,7-11 etc. this let's you specify exactly which pages you'd like to print x-y specifies a range comma separates separate pages example: 1,3,5-7 will print pages 1,3,5,6,7
I forgot to add: cascade/mirror like - left/right indent - left/right edge for page numbers if printed on both sides of the paper The problem is that if you turn the paper in the printer pages and indents will be printed on the opposite side -- see also reverse order above
Created attachment 27287 [details] [review] patch for libgnomeprintui for extended options under cups Here is a patch for libgnomeprintui that adds the options of page-range, page-set and reverse for any capable backend.
Created attachment 27288 [details] [review] Adds abilty to cups backend for pagerange, pageset and reverse To be used in conjection with patch for libgnomeprintui, gives you page-range, page-set and reverse under cups. If anyone is interedted in adding similar options for the other backends, i've got as hacked-up a parser for page-ranges, email me for details.
Note this patch doesn't deal with margins or pagenumbering, as this seems to me to require some sort of communication with the application, and that requires some API design.
While I like the features there is a problem with the implementation. Please see the attached screenshot of the gnomeprint print dialog in gnumeric with the above patches applied. If we select the page ranges 1,3-5 etc we can't specify anymore which sheets to print. I guess the original design gave the application control over what a "page" is. We now should have one area where we can select the region(?) to be printed and one that affects the pages that are really printed. And this has to be backward compatible...
Created attachment 27364 [details] gnumeric print dialog with patch
Yep, I worried about this too. one (quick) option is to move the "page ranges" option to to act like a "page-set" option. I think that ideally the real solution is to deprecate the current "allow an application to define what a page is" and have an interface that allows an application to *add in addition to page selecion* a content selection method. The real problem is that page ranges only really makes sense when the application has a concept of pages, and theres no real way for gnomeprint to find this out.
Well, we have to make sure that the interface is backwards compatible. Of course we can add to the interface. So we should not automatically add the "Page Ranges". In any case, conceptually there should probably be a "Print Range" section that allows the specification of what to print: in gnumeric that would include which sheet, in gedit it may restirct printing to a certain selection. Gnome-print would show that section in the dialog but not act on it. THe application would have to do tha. Separately (and only shown if the application enables it) would be a Page Range section that would contain `All pages', `Pages from...to', and your Page Range, "even only", "odd only". That section would be handled by gnomeprint so the application would not know about it. We could add an enumeration to GnomePrintDialogFlags to indicate that the Page Range section should be visible. It would be great if you could change your patch in this sense.
After taking some time out on this, I realize that really teh only good solution is for libgnomeprint to pass back to the app a bitmap of pages to print, or some such similary structue. I realised this when my girlfriend used the system with my patch and duly freaked out when abiword said 'printing page 1/52, 2/52, ...), when she'd selected range 2-4, 6, 7... I'll quite happily do a patch for this, but its a hell of a lot of work making existing gnome apps use this. :(
*** Bug 151249 has been marked as a duplicate of this bug. ***
See http://mail.gnome.org/archives/gnome-print-list/2005-August/msg00013.html I've implemented advanced page selection on the software side (i.e. transport independent). API remains unchanged (although I'd love to kill the old range API).
Created attachment 51090 [details] GnomePrintPageSelector
Created attachment 51091 [details] GnomePrintPageSelector
Created attachment 51092 [details] [review] patch for libgnomeprintui
Created attachment 51093 [details] Screenshot of GnomePrintPageSelector
Regarding gnumeric (sheets) and gedit (lines): This is something totally independent in my opinion. On one side you've got the content selection ("line x to y" or "sheet z"), on the other side the pages to print (of that content). I.e. applications should provide a GnomePrintContentSelector, and gnome-print will add a GnomePrintPageSelector (see my patches above). That way, you will be able to print only the odd pages of "sheet z".
Created attachment 51495 [details] [review] patch for libgnomeprintui
Created attachment 51496 [details] gnome-print-page-selector.c
Created attachment 51497 [details] gnome-print-page-selector.h
Created attachment 51498 [details] gnome-print-content-selector.c
Created attachment 51499 [details] gnome-print-content-selector.h
Created attachment 51500 [details] Screenshot of gnumeric showing the new page/content selection in action. I've hacked gnumeric a bit. Attached a screenshot that illustrates how I would like to handle page and content selection in libgnomeprintui. First, you select the relevant content (sheet, cells...), then what you would like to print (even pages, only current page...). If nobody complains, I'll check in the relevant code to libgnomeprintui. The patch for gnumeric will be submitted separately.
(1) and (3) are now in CVS. Regarding (2), I'll need to write a filter for reordering. I'd like to combine it with general purpose reordering (like printing 8-1-2-7-6-3-4-5 for a leaflet).
(2) is now in CVS, too (printing in reverse order). This bug can be closed.
*** Bug 326308 has been marked as a duplicate of this bug. ***
Closing. New features should go into the gtk+ printing code.