Bug#850163: xpdf/poppler miscommunication

["Andries E. Brouwer" <Andries.Brouwer@cwi.nl>]

Masanori Goto reports (Debian bug #850163):
"Syntax Error: Missing language pack for 'Adobe-Japan1' mapping"

I see the same problem. A silly workaround is adding links

   /cMap -> /usr/share/poppler/cMap
   /cidToUnicode -> /usr/share/poppler/cidToUnicode
   /nameToUnicode -> /usr/share/poppler/nameToUnicode
   /unicodeMap -> /usr/share/poppler/unicodeMap

With these links in place his example file displays well,
and no error messages are given.

What happens is that xpdf calls poppler, and poppler needs
to find appropriate cMap, cidToUnicode, nameToUnicode, unicodeMap
files and directories. The poppler code that I am looking at says

(poppler/GlobalParams.cc line 671)

const char *dataRoot = popplerDataDir ? popplerDataDir : POPPLER_DATADIR;

and the files mentioned are searched for in %s/cMap etc, where %s is
substituted by dataRoot. The default POPPLER_DATADIR is /usr/share/poppler,
and if this line was simplified to

const char *dataRoot = POPPLER_DATADIR;

then all would work. But the constructor of GlobalParams is called
with an empty string "", and %s/cMap becomes /cMap, which is why
creating these links solves the problem.

I suggest that this be fixed both in xpdf and in poppler.

The poppler fix might be to change the above line into

const char *dataRoot = (popplerDataDir && *popplerDataDir) ? popplerDataDir :
  POPPLER_DATADIR;

The fixed poppler works together with the current xpdf and all is well.

How come GlobalParams("") is called?
The xpdf 3.04 source calls
  globalParams = new GlobalParams(cfgFileName);
where
  static char cfgFileName[256] = "";

It appears that this xpdf call is entirely misguided:
what poppler wants is a directory, a prefix, something like
/usr/share/poppler, but cfgFileName is the name of the
xpdfrc configuration file, the thing set by the -cfg option.

So, in the long run also xpdf needs to be fixed.

Andries