GNOME Bugzilla – Bug 544560
Loading PDF file fails if its path contains non-ascii characters
Last modified: 2012-04-27 14:21:51 UTC
1. Place any PDF file into a directory call e.g. C:\äöü 2. Try to load file Resulting error: poppler.exe Warning Could not open 'C:\Documents and Settings\msi\My Documents\mämömö\a3 pdf sample - Google Search.pdf' for reading: Failed to load document from data (error 1)' The same file load without problems from other directories. The libpoppler files included in the 2.4.6 installer do not include any version information, unfortunately.
Please file this as a bug report against libpoppler then. The GIMP plug-in just passes it an URI created using g_filename_to_uri().
Hm... latest binary available from ftp.gnome.org is 0.64, libpoppler is at 0.8.4. I'll build it myself before reporting anything upstream.
... well, libpoppler is still hard to build, it seems.
My poppler-dev-0.6.4.zip contains the build script called make/poppler-0.6.4.sh that contains some sed invokation and patches (inline in the script). Try using them for poppler 0.8.4, too?
*** Bug 578233 has been marked as a duplicate of this bug. ***
Michael, Tor, any news on this one? How is this a gimp bug anyway?
The file is originally in UTF-8 (the "GLib file name encoding" on Windows), and then it is converter to a URI with g_filename_to_uri(), passed to poppler_document_new_from_file(), which converts it back to a (UTF-8 encoded) filename, which passes it on to PDFDoc::PDFDoc() which just passes it to fopen(). fopen() does not understand UTF-8, it wants system codepage ("ANSI"). There seems to be also a Windows-specific PDFDoc::PDFDOc() that takes a wide-char string. poppler_document_new_from_file() should use that instead on Windows. Somebody feel free to report a bug against pooppler.
Resolving as NOTGNOME, although arguably one could say that GIMP's file-pdf.c should not pass URIs of UTF-8-encoded file names to poppler. But I think in this case that is the right thing to do, as it's specifically poppler's GLib wrapper layer that file-pdf.c is calling, so it should know that file names are in UTF-8 in GLib on Windows.
Nah, the easiest fix would be to just map in the file in file-pdf.c using g_mapped_file_new(), and call poppler_document_new_from_data() instead. No need to wait for poppler maintainers to fix the Windows UTF-8 issue there. Reopening...
Filed as https://bugs.freedesktop.org/show_bug.cgi?id=25032 in Freedesktop's Bugzilla.
Created attachment 147485 [details] [review] Suggested patch Seems to work and fixes the problem.
It's a workaround and such workarounds make it even harder to port the file plug-ins to GIO. But for the moment it's probably the best thing to do.
*** Bug 616269 has been marked as a duplicate of this bug. ***
Seems to work for me too, so let's commit then: commit df24468fde963d158d57d8926c4459f718403335 Author: Tor Lillqvist <tml@iki.fi> Date: Sun May 16 11:00:53 2010 +0200 Bug 544560 - Loading PDF file fails if its path contains non-ascii characters Use poppler_document_new_from_data() instead of poppler_document_new_from_file() to work around filename encoding issues.
Should we cherry-pick that to gimp-2-6, too?
*** Bug 623298 has been marked as a duplicate of this bug. ***
*** Bug 634548 has been marked as a duplicate of this bug. ***
*** Bug 667174 has been marked as a duplicate of this bug. ***
*** Bug 667188 has been marked as a duplicate of this bug. ***
*** Bug 668157 has been marked as a duplicate of this bug. ***