GNOME Bugzilla – Bug 396399
GtkPrintOperation has problems on Mac OS X
Last modified: 2007-04-30 23:33:48 UTC
Steps to reproduce: 1. Make an application that makes use of the PrintOperation class for printing 2. Do not specify any "gtk-print-backends" or "gtk-print-preview-command" manually 3. Try to print from the application or try to use print preview When attempting to print, the application crashes with the following message: dyld: lazy symbol binding failed: Symbol not found: _httpGetFd Referenced from: /usr/local/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.so Expected in: flat namespace When attempting to preview no preview is shown and a message is displayed in the consle: "Error launching preview. Failed to execute child process "evince" (No such file or directory)" Stack trace: Sorry, not my mac -> no trace Other information: creating a .gtkrc-2.0 containing the following line resolves the crash when trying to print put reduces the print interface to lpr functionality: gtk-print-backends = "lpr" adding the following to the same file and wrapping adobe acrobat in a script called acroscript allows preview to work (the script is necessary since accessing the native OS X acrobat reader executable from the command line is not trivial and PrintOperation requires thet the called application delete the temporary pdf). gtk-print-preview-command = "acroscript %f" Evince is not installed on the system, only gtkmm and libglademm with their dependancies. Therefore installation of evince just to get preview working means a lot of overhead.
I believe that this is not a gtkmm, but a GTK+ issue. But, frankly, I don't remember how previewing is supposed to work on Mac OS. Evince is supposed to be the viewer application on Linux, and the native preview dialog is used on Windows. Perhaps on Mac this is determined by Preview.App? Was it set, or generally did print previewing work fine before this in other Mac applications? It seems that here CUPS was detected and assumed to be running on Linux, which is wrong of course.
Marko, You may very well be right that the problem is in GTK+ and I think you put your finger on the problem. Printing from native OS X applications works fine -> cups is configured properly. But it is the mac OS X modified version of cups. Also, print preview in native OS X applications works fine and the problem appears to be a default setting of the preview application to evince. Doesn't mac have a native pdf viewer which could be used? In any case, I did not find any gtkrc files containing a "gtk-print-preview-command" line. Thus 'evince' is a default value coming from elsewhere. It is difficult for me to follow up on this problem since the mac which is acting up is literally half-way around the world and my only access is to the console. I get all the feedback from a user trying to run my programmes. Personally I run linux on an x86 and neither printing nor previewing leads to any problems. Cheers, Burnce
Yes, Preview.App is not used, and Evince is supposed as default. This is how it is ATM, you need to write .gtkrc on your own. Hopefully this will change in future. Someone would need to either write a printing backend for Mac, or make use of Preview.app through .gtkrc.
So someone needs to find or create a GTK+ C test case, or try an existing GTK+ C application that uses this feature.
Regardless of evince vs. Preview.app, the orignal problem is a build problem. Apprently the cups libraries shipped on OS X are missing the httpGetFd symbol. According to the cups documentation, it was introduced in cups 1.2, and the cups backend code does: #ifdef HAVE_CUPS_API_1_2 dispatch->data_poll->fd = httpGetFd (dispatch->request->http); #else dispatch->data_poll->fd = dispatch->request->http->fd; #endif nowadays. This was fixed on 2007-01-17.