GNOME Bugzilla – Bug 753628
user options of wrong printer are used
Last modified: 2015-09-24 16:16:25 UTC
Created attachment 309271 [details] PPD file used for the test case If a printer has the same name name as another printer plus additional characters, user-set printer options are applied to the wrong printer. Steps to reproduce: 1) set up 2 printers (The actual device URI does not play any role. Here: Both printers are configured using the same PPD.): $ sudo lpadmin -p myprinter -v http://printer1.example.org -E -P Test.ppd $ sudo lpadmin -p myprinterwithlongername -v http://printer2.example.org -E -P Test.ppd 2) open any file in Evince (or another GTK+ application) 3) open the print dialog 4) select printer "myprinter" 5) check the value of option OutputMode/"Print Quality": It is set to "Normal" (as specified as default in the PPD file). 6) close the application 7) set a user option for OutputMode for printer "myprinterwithlongername": $ lpoptions -p myprinterwithlongername -o OutputMode=Draft 8) open Evince (or another GTK+ application) again 9) open the print dialog 10) select printer "myprinter" 11) check the value of option OutputMode/"PrintQuality" Observed behaviour: The value of the option OutputMode/"PrintQuality" for the printer "myprinter" is set to "Draft", even though the value was not change for this printer. The user value for this option was only changed for the other printer. Expected behaviour: The value of the option OutputMode/"PrintQuality" for the printer "myprinter" should be "Normal". I checked this with the current "master" in the gtk+ git repository.
Created attachment 309272 [details] [review] patch to fix the bug of options from other printer being used The attached patch fixes this bug.
Created attachment 309274 [details] [review] patch to fix bug 582747, based on the previous patch This additional patch, which is based on the previous patch, should also fix bug 582747. I attach it here because it is based on the patch attached here to fix the bug described here.
(In reply to Michael Weghorn from comment #2) > This additional patch, which is based on the previous patch, should also fix > bug 582747. To clarify my somewhat inexact wording: With "based on the previous patch", I meant that it is created on top of this commit and meant as an additional patch, not as a replacement.
Comment on attachment 309272 [details] [review] patch to fix the bug of options from other printer being used Hi Michael, thank you for the patch. I've pushed it to 3.16 and master branches. I'm going to have a look at the second one.
(In reply to Marek Kašík from comment #4) > Comment on attachment 309272 [details] [review] [review] > patch to fix the bug of options from other printer being used > > Hi Michael, > > thank you for the patch. I've pushed it to 3.16 and master branches. I'm > going to have a look at the second one. Hi Marek, thank you for looking at this and for pushing the first patch.
Comment on attachment 309274 [details] [review] patch to fix bug 582747, based on the previous patch Thank you for this one too. It fixes the problem. I guess that we won't need the lines even if we will ever support instances in the future.
(In reply to Marek Kašík from comment #6) > Comment on attachment 309274 [details] [review] [review] > patch to fix bug 582747, based on the previous patch > > Thank you for this one too. It fixes the problem. I guess that we won't need > the lines even if we will ever support instances in the future. Thank you for looking at the patch. I too think that those lines (that are deleted by the patch) are not needed, but rather counter-productive when implementing printer instances. The desired behaviour then would be that "myprinter" and "myprinter/myinstance" are treated like "two different printers" with their own sets of options (rather than mixing options from the different instances). That is the case when the patch is included. I have made a few thoughts about implementing printer instances in Gtk+. In case I get further with my thoughts, I will write an email to the Gtk+ mailing list. (Or is there a better place to discuss that?)
(In reply to Michael Weghorn from comment #7) > (In reply to Marek Kašík from comment #6) > > Comment on attachment 309274 [details] [review] [review] [review] > > patch to fix bug 582747, based on the previous patch > > > > Thank you for this one too. It fixes the problem. I guess that we won't need > > the lines even if we will ever support instances in the future. > > Thank you for looking at the patch. > > I too think that those lines (that are deleted by the patch) are not needed, > but rather counter-productive when implementing printer instances. > The desired behaviour then would be that "myprinter" and > "myprinter/myinstance" are treated like "two different printers" with their > own sets of options (rather than mixing options from the different > instances). That is the case when the patch is included. Yes, I think that we should have different GtkPrinter objects for different printer instances too. > I have made a few thoughts about implementing printer instances in Gtk+. In > case I get further with my thoughts, I will write an email to the Gtk+ > mailing list. (Or is there a better place to discuss that?) I guess that you can use bug https://bugzilla.gnome.org/show_bug.cgi?id=148184 for that (it is closed now but I will reopen it probably). But I'm not sure whether it is doable right now since I haven't found a way how to get instances via an IPP request (it was a quick look so I could overlook something). We are using those to get list of printers. You can get the instances only via getting of dests right now but we don't use them.
(In reply to Marek Kašík from comment #8) > I guess that you can use bug > https://bugzilla.gnome.org/show_bug.cgi?id=148184 for that (it is closed now > but I will reopen it probably). But I'm not sure whether it is doable right > now since I haven't found a way how to get instances via an IPP request (it > was a quick look so I could overlook something). We are using those to get > list of printers. You can get the instances only via getting of dests right > now but we don't use them. I also don't know of any way to get the instances via IPP request. As far as I know, the CUPS server does not even know of the instances; they are defined by the options set for them in "~/.cups/lpoptions". The only way I know of on how to get them is via the "cupsGetDests()" function from the CUPS API - or by parsing the file "manually" as Gtk+ currently does to get the user options for printers.
Comment on attachment 309274 [details] [review] patch to fix bug 582747, based on the previous patch I've pushed the patch to master. Thank you.