Fedora Account System
Red Hat Associate
Red Hat Customer
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 gtk2-2.9.4-1 cups-1.2.1-16 openoffice.org-core-2.0.3-7.1 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 over again. This patch fixes the second problem.
Both patches look fine, please commit them upstream.
Should be fixed in gtk 2.10.1