GNOME Bugzilla – Bug 543520
Cups custom options are not sent properly
Last modified: 2012-03-15 19:39:45 UTC
Please describe the problem: Cups allows to have custom options where the entry field can be any text instead of just a selector. Gnome handles the user interface properly but does not send the proper string to the cups printer. Steps to reproduce: 1. Using a printer with a custom entry (I created my own ppd file) see: http://www.cups.org/documentation.php/spec-ppd.html 2. In some gnome program, go to the print menu, change that option to some string like "ThisIsAtest", then print. 3. Look at the cups control file that is produced Actual results: The control file will contain the custom option with value "ThisIsAtest" Expected results: According to the cups people, the value should have been "Custom.ThisIsAtest" in this case. Without the "Custom." part ,this is not used by the cups filters. Does this happen every time? yes Other information: Here is the answer to the questions I sent to cups: http://www.cups.org/newsgroups.php?s5135+gcups.bugs+v5139+T1 And here is a related bug: http://www.cups.org/str.php?L2660 And the devel forum message it relates to: http://www.cups.org/newsgroups.php?s41+gcups.development+v51+T1+Qcustom+options
Does this happen with apps using the gtk+ printing api as well?
I checked my current version (gnome 2.22.3 on fedora 9) and it can only happen with the gtk+ printing api. The libgnomeui does not seem to have access to those custom options (I have checked a few programs like tomboy but if you have a better one to try, tell me). I see what I described initially in programs like gedit or evolution (printing and email). When I upgrade to the latest gnome next month I will give it another try to see if it as been fixed.
> I checked my current version (gnome 2.22.3 on fedora 9) and it can only > happen with the gtk+ printing api. Christian: So this is a GTK/printing bug only and has nothing to do with gnome-print? Does this still happen in a recent version? GNOME 2.22 is not maintained anymore.
I just checked under Fedora 11 (gnome 2.26.3) and the same problem is still there (trying print from either evolution or gedit). From what I understand those programs use the GTK print dialogs so I changed the product to gtk+ but I am not sure about the component so I left it at general. BTW for my tests I created a new cups printer with a file URI DeviceURI file:///tmp/printtest (this requires the "FileDevice Yes" option in cupsd.conf) and my ppd attached to that URI has the following lines added: *JCLOpenUI JCLPhone/Phone number (, for pause): PickOne *OrderDependency: 10.7 JCLSetup *JCLPhone *DefaultJCLPhone: interntest *JCLPhone None/No number: "" *JCLPhone internal/68046: "@PJL COMMENT OID_ATT_FAX_DESTINATION_PHONE 68046;<0A>" *JCLPhone interntest/62026: "@PJL COMMENT OID_ATT_FAX_DESTINATION_PHONE 62026;<0A>" *JCLPhone external/9,555-555: "@PJL COMMENT OID_ATT_FAX_DESTINATION_PHONE 9,555-555;<0A>" *JCLCloseUI: *JCLPhone *CustomJCLPhone True: "@PJL COMMENT OID_ATT_FAX_DESTINATION_PHONE \1;<0A>" *ParamCustomJCLPhone Text: 1 string 0 32 and in another section of the ppd: OpenUI Phone/Phone number (, for pause): PickOne *OrderDependency: 45.0 AnySetup *Phone *DefaultPhone: interntest *Phone None/No number: "" *Phone internal/68046: "(68046) pop" *Phone interntest/62026: "(62026) pop" *Phone external/9,555-555: "(9,555-555) pop" *CloseUI: *Phone *CustomPhone True: "pop>" *ParamCustomPhone Text: 1 string 0 32
I should add that the regular option which are part of the same custom group are not processed properly. For example, following the option group seen in my previous comment, If I select 68046 in the GUI then the cups request will contain JCLPhone: 68046 which is wrong and is replaced by the default option (62026) in the ps output from cups. The proper cups request should have been: JCLPhone: internal This works properly for options with no custom entries.
Setting as UNCONFIRMED as question of comment #3 was replied
Created attachment 166104 [details] [review] patch This patch should fix things. One thing to note though is that there is still another bug left. The GtkPrinterOptionWidget does not reload all of the PICKONE_* types. So while the option is loaded from the file, it is not displayed correctly in the dialog.
Created attachment 166109 [details] [review] Patch to correctly load default settings into the dialog OK, this one is only compile tested. Can't run anything in my jhbuild env right now, everything is crashing ...
Created attachment 166764 [details] [review] New patch This patch correctly supports the default values. Values entered manually will be appended with Custom., others are just passed over to cups.
Hm, one thing. For numeric values, it looks like it filters the value even for values that are selected from the list. It should not be filtered if the value is selected from the combobox.
Created attachment 168189 [details] [review] add Custom. prefix to custom options + set values to PPD values Hi, this patch add "Custom." prefix to custom values. It does it only for CUPS backend since this is not mentioned in PPD spec. It also set option value to the value from PPD if a PPD translation of such a value is entered by user (this handles also the case when the value is selected by the combo box). Regards Marek
Review of attachment 168189 [details] [review]: ::: gtk/gtkprintunixdialog.c @@ +4138,3 @@ + + if (match_id != -1) + new_value = g_strdup_printf ("%s", option->choices[match_id]); The strdup here appears unnecessary, since you are not modifying the string in any way. In fact, you could probably just move the gtk_print_settings_set call into the if in the loop.
Hm, OK. Some notes about the patch that seem weird to me (not saying that mine is perfect): 1. I would say it is the job for the GtkPrinterOptionWidget to figure out that the user entered text is in the option list. Not the job of the Dialog. (ie. the assign_choices function is in the wrong place IMHO) 2. It looks to me like your patch does not solve the problem of loading the options from a file again (which mine does, but that part of my patch should be compatible with your changes). 3. Adding the Custom. string in add_cups_options seems good (that way it will not end up in the GtkPrintSettings) I think I'll cook up (a) new patch(es) today based on both patches (and also provide a fix for the filtering issue mentioned earlier).
Created attachment 168512 [details] 1 - Patch to prepend Custom. This patch is basically just the second part of Marek Kasik. Except for one change and that is that a value of zero length (value[0] == '\0') is also interpreted as a custom option.
Created attachment 168513 [details] 2 - Patch to fix up GtkPrinterOptionWidget GtkPrinterOptionWidget fixes, to support loading values again. If an option from the list is typed in, it will return the value from the list instead of the string. I'll attach an alternative that does not do this. It seems weird to me to select the item from the list like this, especially as it will not work for PASSCODE, INT and other fields where typing in strings is impossible
Created attachment 168514 [details] 2 - the real one, alternative one Sorry, just attached the wrong patch earlier.
Created attachment 168515 [details] [review] 2 - the second way, which I prefere
Hi Benjamin, sorry for my late response (I didn't add me to cc, I thought that bugzilla does it automatically when I attach a patch). I see now that it is better to not have the code in the gtkprintunixdialog.c. I would prefer the patch which you don't prefer (the alternative one) since I think that users will enter values in the field even if they are listed in the combo. Other than that I have only two comments to the patch: 1) remove the g_print() + { + g_print ("selected manually from the list: %s, %s\n", name, val); + *custom = FALSE; 2) add -1 to the end of requested values in + gtk_tree_model_get (model, &iter, VALUE_COLUMN, &val, + NAME_COLUMN, &name); What do you think about it Matthias? Regards Marek
Ah, good catch. Yeah, lets do the match based on the string, as suggested by you (I kinda switched sides now; turns out different people seem to have quite different opinions on this). It might be even better to split it up into two separate widgets, but that is just UI tweaks.
Created attachment 192379 [details] Patch to prepend Custom. Updated patch to apply cleanly to GTK+ master.
Created attachment 192380 [details] [review] neccessary updates to the UI code Updated the patch to GTK+ 3.0. There are some small changes here because of the combobox changes.
PING Any chance of getting these fixes reviewed so they can be committed?
Hi Benjamin, I'll try to review the patch before Christmas. Marek
Hi Benjamin, thank you for those patches. They are OK for me to commit with two modifications. The first one is just because of styling: + value = g_strdup(gtk_entry_get_text (GTK_ENTRY (gtk_bin_get_child (GTK_BIN (combo))))); - there should be break after g_strdup The second one is that variables 'val' and 'name' in combo_box_get() should be freed if not needed anymore. Regards Marek
Created attachment 204713 [details] Strip Custom. from the default value that cups passes in I pushed both patches to master and gtk-2-24. While doing a final test before pushing, I noticed a small issue. When a default custom value is set in cups, the GTK+ print dialog will contain "Custom.asdf" as the value, instead of just "asdf". Here is a patch that removes the "Custom." string from the PPD before storing the default value inside GTK+. (If you prefere, I can also open a new bug about this).
(In reply to comment #25) > While doing a final test before pushing, I noticed a small issue. When a > default custom value is set in cups, the GTK+ print dialog will contain > "Custom.asdf" as the value, instead of just "asdf". I don't think that this is an issue since the value is not among listed options. It is a custom option. PPD specification says: "If a *Default keyword is part of an entry, its value must be one of the options of the main keyword in the entry, or it may be Unknown." So the only default option which we should handle better is "Unknown". Marek
I am not sure why this is relevant. "Custom" options are not even part of the PPD specification, but instead are an extension by Cups, so it seems logical that the PPD specification does not allow custom options to be set as the default. One could even argue that "Custom" is one of the listed options (it is implicitly added by Cups) and by using "Custom.string" you are actually selecting the "Custom" option. But even then; what I expect from a users point of view, is that a default value specified in Cups will be loaded by all applications. So if I set set the "Username" option to be "benjamin" using the Cups webinterface, I expect this to be loaded into the GTK+ print dialog. And right now it is loading "Custom.benjamin" as the custom value, and then sending "Custom.Custom.benjamin" back to cups. Benjamin
OK, I see what I did wrong before. I added the default custom option directly to the PPD file without the "Custom." prefix. When I'm adding it through the web interface it adds the prefix and the patch is a need. The only remark I have is a stylistic one. Could you add spaces around the '+' in "ppd_option->defchoice+7" ? After that it is ok with me to commit it. Thank you Marek
Ah :-) Thanks a lot for the quick review! I added the whitespace, and pushed to both master and gtk-2-24. So, I think it is save now to resolve this bug as fixed, Benjamin
This crashes Firefox when printing. Backtrace:
+ Trace 229526
Reverting the commit (8170436e61ea68c713d75ad374d22c3261be9203) lets me print again.
Hi Jan, thank you for the backtrace. Could you attach here the PPD you use for the printer? Regards Marek
Created attachment 206270 [details] PPD for crash It's a remote printer. Here's the PPD that cups server uses.
I'm seeing the crash too, backtrace looks similar. As an additional data point: cups with debug enabled prints out 16:28:41.971 ppdPageSize(ppd=0xb20d5e20, name="Custom 612.00x792.00") 16:28:41.971 ppdPageSize: Size not found, returning NULL just before the crash.
Created attachment 206297 [details] backtrace crash thunderbird print with gtk2-2.24.9
crash printing in thunderbird. Firefox prints ok.
Created attachment 206298 [details] ppd used for printing, Canon iP4300 with turboprint if helpful, I attach my ppd here.
Crash occured in Arch linux where gtk2-2.24.9 is actual repository version. See https://bugs.archlinux.org/task/28118#comment88469
downgrading package gtk2 in Arch linux (2.24.9-1 => 2.24.8-1) fixes this issue.
Uh, outch. I remember seeing this bug at some point, and figuring out that the trouble was somewhere between mozilla, gtk and libcups. IIRC the problem is that Firefox tries to use custom page sizes, even though the PPD does not support this. GTK+ passes the request on to cups, which then crashes. I hadn't thought, that this problem only exists with the patches applied; and I have no good idea how to fix this right now.
(In reply to comment #39) > Uh, outch. I remember seeing this bug at some point, and figuring out that the > trouble was somewhere between mozilla, gtk and libcups. IIRC the problem is > that Firefox tries to use custom page sizes, even though the PPD does not > support this. GTK+ passes the request on to cups, which then crashes. > > I hadn't thought, that this problem only exists with the patches applied; and I > have no good idea how to fix this right now. as I'm the current gtk+ maintainer in Arch, I'll revert this change until a proper fix is committed.
I understand if you pull the patch from the distro again; that seems sane. So, I do think that the patches applied in this bug are correct. Of course, we uncovered a pretty bad problem in mozilla, however I am not convinced that this is even a GTK+ bug. If a printer does not support arbitrary page sizes, then setting one, as done by firefox, is not a valid operation. Of course, GTK+ could at least guard against the crash in libcups.
Inkscape crashes as well:
+ Trace 229555
Created attachment 206452 [details] [review] patch fixing the crash Hi, I'm able to reproduce the problem now. Here is a preliminary patch. I'll continue on it tomorrow. I need to check one more thing still. Regards Marek
I've committed a patch fixing the crash to 2-24 and master. Thank you all for your help. Regards Marek
(In reply to comment #44) > I've committed a patch fixing the crash to 2-24 and master. > Thank you all for your help. I'm sorry to report this, but the patch breaks building if you don't have cups API 1.2. See below for the output of gcc. Every other usage of the 1.2 API is guarded with #ifdef HAVE_CUPS_API_1_2 ... #endif Here is the error message: gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../gtk -I../../../gtk -I../../../gdk -I../../../gdk -DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/X11R6/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/atk-1.0 -DG_ENABLE_DEBUG -DG_ERRORCHECK_MUTEXES -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -I/usr/X11R6/include -DGDK_PIXBUF_DISABLE_DEPRECATED -O2 -g -pipe -m64 -Wall -MT gtkprintbackendcups.lo -MD -MP -MF .deps/gtkprintbackendcups.Tpo -c gtkprintbackendcups.c -fPIC -DPIC -o .libs/gtkprintbackendcups.o gtkprintbackendcups.c: In function `add_cups_options': gtkprintbackendcups.c:516: error: `ppd_coption_t' undeclared (first use in this function) gtkprintbackendcups.c:516: error: (Each undeclared identifier is reported only once gtkprintbackendcups.c:516: error: for each function it appears in.) gtkprintbackendcups.c:516: error: `coption' undeclared (first use in this function) gtkprintbackendcups.c:520: warning: implicit declaration of function `ppdFindCustomOption'
(In reply to comment #45) I opened bug #672182 for this.