GNOME Bugzilla – Bug 737779
Poppler-data not installed or not working in OSX release
Last modified: 2015-12-13 20:51:21 UTC
A user reported that poppler-data may not be working, or else not included in the OSX plugin. See bug 733525, comment 22 and 24. Could someone check if this package is included in our OSX package? There may be an additional issue that, even when included, it won't work, since OSX uses self-contained packages. This should be actually tested (import a pdf with asian characters. If they import well, poppler-data are used). If this issue is confirmed, we may want to use a GlobalParams() with a custom POPPLER_DATADIR (built relatively to the actual path where the package is installed), as proposed by the user. I can't do any of these since I don't know how the OSX release is built, and I have no OSX machine to test any of these. So I let others take care of it.
I just tried and included the poppler data files into my official Mac build manually. Sadly, it doesn't do the job, so it needs further investigation. For a testcase, see bug #733525. Just out of curiosity, is it right to assign this bug to Jernej, the Windows packager? If not, then let's keep this field blank.
su-v: you did a patch for Inkscape. Would you be kind enough to do one for GIMP too? Thanks. Sven: no idea who should be the bug owner. This was the default from Bugzilla for this "installer" component.
@Jehan - I'm sure Sven can do that better than me (I can confirm his findings that simply copying the poppler data files into the GIMP app bundle is not sufficient).
The Installer component is meant to be the Windows installer. Please do not use it for anything else.
Maybe we should use it for all sorts of packaging problems tho...
Here is su-v's fix for inkscape, from bug 733525: http://bazaar.launchpad.net/~inkscape.dev/inkscape/osx-packaging-update/revision/13546
Hey so, for someone with a OSX. After a few min of searches on the web, the fix should be something like the following in plug-ins/common/file-pdf-load.c: Likely somewhere at the start of run() as an initialization (before any other poppler call). #ifdef PLATFORM_OSX gchar *poppler_datadir = ... /* <- obtain the right prefix for poppler, assuming GIMP is installed in the same prefix in the OSX bundle. Probably use _NSGetExecutablePath() to know the plugin running path and get the install prefix relatively to the plugin binary. */ if (poppler_datadir != NULL) { globalParams = new GlobalParams(poppler_datadir); } #endif And that should be it. Now there is the problem that this GlobalParams seems to be only constructable as a C++ class (thus usage of `new`) and I can't see a C wrapper for building it in a pure C way in the glib/*.h headers of libpoppler. This may be a problem unless we compile this plugin as a C++ source instead. I unfortunately can't provide a patch because I have no access to OSX. But that should be quite possible to find a solution with these few pointers, no? Then we will be able to close this bug. :-)
(In reply to Jehan from comment #7) > Hey so, for someone with a OSX. After a few min of searches on the web, the > fix should be something like the following in > plug-ins/common/file-pdf-load.c: > Likely somewhere at the start of run() as an initialization (before any > other poppler call). > > #ifdef PLATFORM_OSX > gchar *poppler_datadir = ... /* <- obtain the right prefix for poppler, > assuming GIMP is installed in the same prefix in the OSX bundle. Probably > use _NSGetExecutablePath() to know the plugin running path and get the > install prefix relatively to the plugin binary. */ > if (poppler_datadir != NULL) > { > globalParams = new GlobalParams(poppler_datadir); > } > #endif > > And that should be it. > Now there is the problem that this GlobalParams seems to be only > constructable as a C++ class (thus usage of `new`) and I can't see a C > wrapper for building it in a pure C way in the glib/*.h headers of > libpoppler. This may be a problem unless we compile this plugin as a C++ > source instead. In which case it would probably be easier to separate this C++ bit in a separate file that is compiled as C++ code (and only on Mac OS) and then linked together with the original file. Worse, we would have to apply this hack to any other plugin that would want to use poppler in the future. The real problem is that poppler is not relocatable on OS X. We cannot really fix it in general through bundles because from the plug-in executables we do not automatically get the correct bundle root. So instead I've simply patched poppler to support a POPPLER_DATADIR environment variable that we set in the launcher script.
Fixed in 2.8 branch (> 2.8.16), and the fix will be included in the upcoming 2.8.16 DMG release. commit 3d5ef9d26601f0e35d77fe1b550b917af3e8fea0 Author: Kristian Rietveld <kris@loopnest.org> Date: Sun Dec 13 21:47:42 2015 +0100 Bug 737779 - Poppler-data not installed or not working in OSX release The main problem is that poppler-data is not relocatable on OS X (it is on Windows for example). Apply a tiny patch to poppler that accepts a POPPLER_DATADIR environment variable, which we set in the .app launcher script. Also include poppler-data in the resulting app bundle.