Red Hat Bugzilla – Bug 197464
gtkunixprintdialog: Trying to print on a printer class kills OO.o
Last modified: 2007-11-30 17:11:36 EST
My local printer (usb2 Brother HL 5050) is accessed through several printing
paths : default PS driver, PS with vendor PPD, PCL
I've defined a general local printer class which groups the 3 aforementionned paths
Just selecting this class in OO.o print dialog causes OO.o to crash
If it changes something, this is a x86_64 system
If simply just selecting it causes some sort of crash then it's likely a problem
with the gtk print stuff.
caolanm->mclasen: does anything else actually use the gtk print dialog yet to
verify that it's a generic issue ?
caolanm->nicolas: if you tick "tools->options->openoffice.org->general->use
openoffice.org dialogs" then you get the "classic" openoffice.org print and file
dialogs, if you do this and visit that printer in the classic dialog does it
function correctly ?
The native OO.o dialogs work
But they don't try to display a lot of the info the gtk2 ones do, and I since
printer classes do not expose some of this info like normal printers, that would
explain the crash
CCing John, who wrote all of the cups backend code
Nicolas, just to clarify: It works if you select a regular printer (as opposed
to a class) ?
If it didn't I'd have opened another vengeful bug ;)
I tracked this down to two bugs.
First and the easiest to fix is that when requesting a ppd from a class we must
request a ppd from the first printer in the class. This was not seen in
previous tests because the printer name and the class name were the same.
The second issue is that when the GET fails to get the PPD is should try again
only a finite number of times. For some reason it keeps trying. That will take
a bit more digging to fix.
Created attachment 131968 [details]
Gets the correct ppd name if we find a class
This should fix the first issue. It is not quite a complete fix. In CUPS 1.2
you can have classes of classes. Cups handles this by recursively going down
the tree, getting a new connection, and checking the first printer of the class
until it finds an actuall printer. This is easy to do using blocking calls but
much harder in our async world view. It is also costly since one needs to get
a new connection for each branch of the tree it decends down into. Also Cups
seems to allow circular refrences so you can have one class that contains a
class that contains the first class. Don't ask me why they didn't put the
logic in the server for getting ppd's from classes.
Created attachment 131970 [details]
Fix the parameters we send when emitting the details-acquired signal
For some reason we were sending in the printer as a parameter which got
marshled as the success boolean. This cause the signal to always say it had
succeeded and call the selected_printer_changed method which would check for a
PPD, see it was not found and call request_ppd which would start the cycle all
This patch fixes the second problem.
Both patches look fine, please commit them upstream.
Should be fixed in gtk 2.10.1