After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 582747 - Print dialog sets wrong printer options
Print dialog sets wrong printer options
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Printing
3.3.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-05-15 10:20 UTC by patrick
Modified: 2015-09-24 16:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fixes this bug (2.17 KB, patch)
2012-01-06 18:28 UTC, patrick
none Details | Review

Description patrick 2009-05-15 10:20:35 UTC
Please describe the problem:
Print dialogs created by gtk_print_operation_new() set the wrong options on cups printers that have "instances" defined in /etc/cups/lpoptions or ~/.{,cups/}lpoptions

Instances are defined for example like this (in the mentioned files):

---snip---------------------------------------------------
Default CMP600 CNDensity=-10 CNGamma=1.4 ...
Dest CMP600/Draft CNDensity=-10 CNGamma=1.8 ...
---snap---------------------------------------------------

this snippet defines:
- on the first line: the options for a "Default" (could also be "Dest") printer "CMP600"
- on the second line: another "instance" of that printer called "Draft", with different options

The code in gtk silently ignores the fact that the second line defines "instance" options and sets the options for the default instance of the printer, which is the only instance showing up in the print dialog as the gtk_print_operation_new dialog doesn't handle instances at all (yet).

The relevant code is in
file /modules/printbackends/cups/gtkprintbackendcups.c
function cups_parse_user_options():

---snip---------------------------------------------------
      /* NUL-terminate the name, stripping the instance name */
      name = lineptr;
      while (!isspace (*lineptr) && *lineptr)
        {
          if (*lineptr == '/')
            *lineptr = '\0';
          lineptr++;
        }
---snap----------------------------------------------------

I would suggest to remove that statement
>            *lineptr = '\0';
and put
>            break;
instead.

I am just going to check if that would work now...


Steps to reproduce:
1. declare some instances (with kde printers control for example: "$ kcmkcmshell printers")
2. cat the relevant files "cat /etc/cups/lpoptions ~/.{,cups/}lpoptions" to make sure they show up there. the bug probably only occures if the instances are declared _after_ the default printer options as the code then overwrites the default options


Actual results:
3. hit control-p to print from gedit / firefox / evoultion / ... and notice that the options for your printer are those declared in the instance declared _last_ in the lpoptions config files


Expected results:
the default options should show up instead of the instance options

Does this happen every time?
yes

Other information:
it should be mentioned that gnome-cups-manager sems to handle this correctly already and much of the code is anyway duplicated there. but gnome-cups-manager seems not to be used that much
Comment 1 patrick 2009-05-15 10:38:16 UTC
:-) well, no, of course my suggested fix wouldn't work since what we we'd actually want to do is "continue" the outer loop. But before I use "goto" lets wait if somebody else has an elegant solution to this.
Comment 2 patrick 2009-05-15 11:27:56 UTC
Ok, now. Here you go:

--- gtk+2.0-2.16.1/modules/printbackends/cups/gtkprintbackendcups.c.orig        2009-05-15 13:11:43.000000000 +0200
+++ gtk+2.0-2.16.1/modules/printbackends/cups/gtkprintbackendcups.c     2009-05-15 12:59:32.000000000 +0200
@@ -1898,12 +1898,14 @@
       if (!*lineptr)
         continue;

-      /* NUL-terminate the name, stripping the instance name */
+      /* NUL-terminate the name, skipp instances */
       name = lineptr;
       while (!isspace (*lineptr) && *lineptr)
         {
-          if (*lineptr == '/')
+          if (*lineptr == '/') {
             *lineptr = '\0';
+            break;
+         }
           lineptr++;
         }


It might not be _that_ elegant, but it just works (tm) and makes me happy. It's against (debian testing/unstable) version 2.16.1-2 and I tested it there and will be using it.


Side note:

This bug was making me almost mad for ages now. It took me a long time to get mad enough and start really attacking it. And it was great fun! I love open source software. If your PC doesn't behave the way you like, you just find out why and fix it. Once again I took the often heard "Use the source, luke!" seriousy and tracked the issue down to a simple "break;" statement :-)) I'm just happy now and hope so will some others be after the bugfix travels its way down into the distros.

Cheers

Patrick
Comment 3 patrick 2009-06-06 15:56:18 UTC
feedback ?
Comment 4 André Klapper 2012-01-06 16:05:32 UTC
Hi Patrick, sorry this didn't get any feedback so far.
Is this still a problem in gtk+ 3.2 or 3.0?
Comment 5 André Klapper 2012-01-06 16:05:56 UTC
Also, can you please attach patches as attachments? Otherwise they are not visible in the review infrastructure. Thanks...
Comment 6 patrick 2012-01-06 18:28:17 UTC
Created attachment 204768 [details] [review]
Fixes this bug
Comment 7 patrick 2012-01-06 18:29:42 UTC
Hi André

It is currently not a problem for me. (I'm not using KDE any more at all and gave up trying to keep printer "instances" around. As a workaround I am just copying entire "printers" (To have "color", "b/w", "draft", "envelope" configs around to be used straight away instead of having to dig into the config dialogs every time i print something).

I do still think "instances" would be quiet useful.

And I believe the bug is still present, even in the gtk+ git master branch. Here is a patch.

https://github.com/P2000/gtk/commit/70d1296
Comment 8 André Klapper 2012-01-06 19:17:57 UTC
Thanks! Bumping version as per last comment.
Comment 9 Marek Kašík 2015-09-24 16:18:15 UTC
This has been fixed by a patch from Michael Weghorn. See https://bugzilla.gnome.org/show_bug.cgi?id=753628#c2 and https://git.gnome.org/browse/gtk+/commit/?id=bf9c9f17627ebd049d8b2b5ccc6bab27ce37fcca.