I'm cross-compiling poppler for Win32 using a mingw32 toolset (not using Cygwin), and have run into a minor issue with GlobalParams::scanEncodingDirs().

The problem is that the entries in the POPPLER_DATADIR/nameToUnicode directory are all passed to parseNameToUnicode(), and this includes the "." and ".." entries. Naturally, these cannot actually be read as nameToUnicode files, and so error messages are printed:

Z:\Volumes\Beta\xmingw32\poppler-0.6.1\build-mingw\utils>pdftotext.exe sample.pdf
Error: Couldn't open 'nameToUnicode' file 'Z:\usr\local\mingw\share\poppler\nameToUnicode'
Error: Couldn't open 'nameToUnicode' file 'Z:\usr\local\mingw\share\poppler'

The tool continues, and executes successfully, but these messages are disturbing.

I don't know if this would behave in the same way if built with other Windows tools and/or libraries, but I think a clean mingw32-based build would be desirable.

To solve this, I suggest passing gTrue to the GDir constructor, so that it stats the directory entries, and then skip the call to parseNameToUnicode if isDir() is true. Proposed patch follows (hoping the web form doesn't mangle it):

========================================
diff --git a/poppler/GlobalParams.cc b/poppler/GlobalParams.cc
index cf97e78..a6d49d2 100644
--- a/poppler/GlobalParams.cc
+++ b/poppler/GlobalParams.cc
@@ -655,9 +655,10 @@ void GlobalParams::scanEncodingDirs() {
   GDir *dir;
   GDirEntry *entry;
 
-  dir = new GDir(POPPLER_DATADIR "/nameToUnicode", gFalse);
+  dir = new GDir(POPPLER_DATADIR "/nameToUnicode", gTrue);
   while (entry = dir->getNextEntry(), entry != NULL) {
-    parseNameToUnicode(entry->getFullPath());
+    if (!entry->isDir())
+      parseNameToUnicode(entry->getFullPath());
     delete entry;
   }
   delete dir;
========================================