GNOME Bugzilla – Bug 535158
can't rearrange the order of multi pages per side
Last modified: 2009-02-18 13:28:31 UTC
When Hebrew users (and Arabic, and all other right to left languages) want to print more than one page per side (I'll use 2 pages per side as an example), they would usually want to print the first page on the right of the landscaped page, and the second page on the left of it, so the float of the page will match the float of reading. The current printing dialog of evince doesn't support it, and all documents are printed as if they were left to right. Please add an option to select the order of the pages on the printed side. there should be four general options of which the user would pick from: left-to-right, left-to-right, upside down right-to-left right-to-left, upside down thanks.
Evince uses the gtk+ printing system, so reassigning to gtk+. Thanks for reporting.
It would be great if this feature will be added. The only thing needed to be added is the four options mentioned above (by the original author). If you need help, the Hebrew community will be glad to help (I am not sure if there is someone which knows how to write patches for gtk+, but...).
voting for this one
Created attachment 116493 [details] [review] allows user to specify layout of pages per sheet in number-up mode Hi, this patch allows users to change layout of page in number-up mode. The set of layouts is the same as in the number-up-layout attribute of CUPS (http://www.cups.org/documentation.php/spec-ipp.html). Regards Marek
Marek: When your patch will be added? How can we test it?
First comments after trying this patch for a bit: I think the combobox approach you took is fine in general, and it is good that the combo is insensitive when printing only one page per side. As a small improvement, it would be cool if the list of choices would be only "left to right" and "right to left" if I print two pages per side. I'm not so sure if the lable "Layout of page" is right. If you compare to the 'Pages per side' label we use to lines up, it would be more correct to say 'Layout of side', but that just sounds odd. How about 'Page ordering' ? I think it would be good to have the layout combo directly below the 'pages per side' combo. I think moving the two-sided combo up to the top may be best. Random question for the Hebrew speakers in CC: Would you expect the default value to depend on the text direction, ie default to right-to-left for hebrew ? I haven't looked at the implementation yet.
I think that the default ordering should be depend on the language settings (LANG environment variable?), when using Heberw or Arabic it should be right-to-left. thanks.
gtk_widget_get_direction() is the function to get the text direction.
Created attachment 116668 [details] [review] reworked patch Hi, this version of the patch : 1) changes the list of choices according to "Pages per side" 2) changes "Layout of page" to "Page Ordering" (it is similar to my first idea :) ) 3) swaps positions of "Pages per Side" and "Two-sided" combos 4) sets default ordering according to text direction Regards Marek PS (To Ofir): You can download GTK+ from SVN, apply patch, build it, install it and test it. ( svn checkout http://svn.gnome.org/svn/gtk+/trunk gtk cd ./gtk/ patch -p0 < ../number_up_layout.patch ./autogen.sh --prefix /usr/local make su make install exit gtk-demo - you will also need libraries pango and glib (see www.gtk.org - similar procedure)
If you want to test this without installing a patched gtk (ie out of a local build), then you need some trickery to get the right printbackend to be loaded. What I do in that case is cd $BUILDROOT mkdir printbackends ln -s modules/printbackends/cups/.libs/libprintbackend-cups.so printbackends export GTK_PATH=$BUILDROOT With this, e.g. tests/print-editor will pick up the print backend from the local build, not the installed one.
Looking at the patch now... case GTK_NUMBER_UP_LAYOUT_LEFT_TO_RIGHT_TOP_TO_BOTTOM: + { + start_x = 0; + end_x = pages_x - 1; + start_y = 0; + end_y = pages_y - 1; + dx = 1; + dy = 1; + horizontal = TRUE; + }break; the extra {} here are unnecessary and should be dropped. + gtk_printer_option_set_remove (set, gtk_printer_option_set_lookup (set, "gtk-n- up-layout")); The code should probably handle the case that there is no gtk-n-up-layout option. I dislike how the code for construcing the option is duplicated between the cups backend and the dialog. Here is an alternative idea: keep the original fully populated option around (ie keep a pointer in priv, so you can keep it around even if it is not currently part of the option set), and construct the reduced 2-choice option by copying parts of the original option, if you know what I mean. One tricky detail to get right here is to map the current selection to the reduced set of options. Ie, you should look at the "lr" vs "rl" aspect of the currently selected option and preserve that. + option = gtk_printer_option_new ("gtk-n-up-layout", "Page Ordering", GTK_PRINTER_OPTION_TYPE_PICKONE); "Page Ordering" should be translated here, no ? I'm somewhat irritated that none of the labels in cups_printer_get_options seems to be translated... How does this acutally take effect in the end ? I assume page-up-layout is a cups attribute that the server will interpret correctly ? Does the lpr code have any effect ? If not, it should just be dropped.Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade.
Created attachment 116944 [details] [review] reworked patch Hi Matthias, this patch changes implementation according to your previous comment. But I implemented the changing of list of choices in a little different way. I removed constructing of the option from the cups backend. It is not needed there, because initial setting of option "number-up" is "1". The relevant list is created after change of "number-up" inside of GtkPrintUnixDialog. I also dropped the code from lpr backend. It had no effect. I added translation flag "_()" to all labels in cups_printer_get_options. This version preserves setting of the option across change of "number-up". I removed the "+ gtk_print_settings_set (settings, "cups-number-up-layout", gtk_print_settings_get (settings, GTK_PRINT_SETTINGS_NUMBER_UP_LAYOUT));" line. Which was probably meant by the "How does this acutally take effect in the end ? I assume page-up-layout is a cups attribute that the server will interpret correctly ?" comment, wasn't it? Marek
> I removed constructing of the option from the cups backend. Hey Marek. I'm sorry, but I think that is wrong. Because the number-up-layout is something thats implemented by cups, the option must come from the cups backend. If we e.g. grow a papi backend, it would be up to the papi backend to decide whether it supports number-up-layout or not. > I assume page-up-layout is a cups attribute that the server will interpret correctly ? This is what my question was about, and I have now gone and verified it. number-up-layout is a cups extension of IPP, available since cups 1.1.15
Created attachment 117050 [details] [review] reworked patch Hi, the option is constructed inside of cups backend in this version. But I couldn't simply copying parts of this option to construct the 2-choice option. The content of choices_display is different. I also added control of CUPS version (>= 1.1.15). Marek
This patch looks ok, thanks.
+ if (strcmp (val, "lrtb") == 0) + return GTK_NUMBER_UP_LAYOUT_LEFT_TO_RIGHT_TOP_TO_BOTTOM; + + if (strcmp (val, "lrbt") == 0) + return GTK_NUMBER_UP_LAYOUT_LEFT_TO_RIGHT_BOTTOM_TO_TOP; + + if (strcmp (val, "rltb") == 0) + return GTK_NUMBER_UP_LAYOUT_RIGHT_TO_LEFT_TOP_TO_BOTTOM; [etc...] Why use these extra made-up strings instead of using the nick values of the GtkNumberUpLayout enum type with a function like _gtk_builder_enum_from_string, and doing the reverse in gtk_print_settings_set_number_up_layout and update_number_up_layout? Also this code seems to be duplicated between gtkprintsettings.c and gtkprintunixdialog.c.
Hi Christian, I used these strings because this style is used in other functions of gtkprintsettings.c as well (for example get/set_quality). I used this also in gtkprintunixdialog.c because it is used this way there too (dialog_get_pages_per_sheet () - it also converts strings to values. This parameter is very similar to the number-up-layout parameter.). I wanted to preserve the style of these source files. Unfortunately, I already committed the patch to svn (before reading the comment from you). So, should I leave this bug opened and change those functions or can I resolve it? Regards Marek
Christian, those 4-letter acronyms are what cups expects as values of the number-up-layout attribute...
Yes, but here these 4-letter strings are also used to store the setting in the GtkPrintSettings object which is backend-independent (other backends might expect other strings). IMHO it would be good to keep these settings in a format easily de/serialised with the gtype system, which the value nicks would provide. The CUPS backend can then translate it to the values it expects... It's not hugely important though, but if you want I could try to write a patch for this.
Sure, if you want to write a patch, why not.
Hi Christian, all values in GtkPrintSettings are stored as (gchar *). Functions gtk_print_settings_set/get store/return only such strings. All other functions (gtk_print_settings_set/get_int/bool/double/length and derived functions) use the basic set/get functions. So, one possible way to change it is to change the most of the GtkPrintSettings functions. Marek
Created attachment 117600 [details] [review] patch implementing my suggestion from comment 16 This should do it, but unfortunately I'm unable to test this since I have no printer and the "file" backend doesn't support this new feature. Not sure anymore it's worth it, but here's a patch for you to decide :)
Hi Christian, the patch doesn't work. The ordering of pages is always from left to right, top to bottom. You can add virtual printer to your CUPS to test it. It is enough to permit file device printer in /etc/cups/cupsd.conf (add line "FileDevice Yes"), get PPD of printer which is able to print in number-up mode and set up new printer with this ppd with device URI "file:/tmp/output.prn". (For example, this one works: http://www.daimi.au.dk/~xlpr/ppd/CNR317CE1.PPD) Then you can view the print using Evince, gv or any other postscript viewer. Regards Marek
Created attachment 117843 [details] [review] updated patch This should fix that problem.
Hmm, alternatively, how about some careful use of /*< nick=lrtb >*/ to make the nicks identical to the values expected by cups ?
Created attachment 117978 [details] [review] alternative Not sure this is significantly better. But it avoids yet-another-string-mapping-table in the cups backend.
Marek, can you check that the latest patches don't break the layout feature ?
Christians patch doesn't seem to work. Probably because the gtk_printer_option_widget_get_value call in dialog_get_number_up_layout actually returns one of the 4 letter acronyms instead of the nick.
So to fix this, we'd have to duplicate the mapping table in the dialog. Not very attractive
I think using <nick=...> would be good for 2.14.0; everything else in the patch doesn't change ABI and can thus be postponed.
Created attachment 118001 [details] [review] matthias's code with few modifications Hi, Christian's patch partially works. It doesn't redraw page layout preview right. Matthias's patch partially works too :). It doesn't set initial value of "Page Ordering" for 2 pages per sheet. I corrected Matthias's patch. Regards Marek
Thanks, lets go with that working patch then.
If this patch has been included in gtk 2.15.3 it does not work. Pages are printed always in the same order, no matter which option you choose 1 2 3 4
To make your comment heard, you need to reopen this bug. Also, please provide some more details on the scenario in which you see this not working. What app ? What printing backend ? What kind of printer ?
Sorry, I'm not really familiar with this... I'm printing using evince and cups. I have an USB printer by samsung. I change "page ordering" and hit "print preview". the page ordering has not been changed
Well, anyway this bug is fixed, since now a page ordering dialog exists. My problem is that the option does nothing, should I open a new bug?
Also, I realized that page ordering works in firefox, gedit and eog. only evince does not work. So please close this bug: I will open a new one against evince
Hi Nicolò, Evince pre-process documents itself. So, the problem is that Evince doesn't implement rearranging of the order of pages per side. This will be solved by fix of the bug #557112. Regards Marek P.S.: I'm closing this bug with resolution 'FIXED'