If you prefer to give that program a different name, let us call it xyzpdf. So, the situation is that there is a widely used program called xyzpdf. This program uses libpoppler, that is, ldd shows
% ldd /usr/bin/xyzpdf ... libpoppler.so.58 => /usr/lib/x86_64-linux-gnu/libpoppler.so.58 Now this libpoppler as used by this program fails to work. Maybe libpoppler is not buggy, but it blindly uses invalid data. A very simple fix would make it slightly more robust, and make many open source users happy. I propose to change >> const char *dataRoot = popplerDataDir ? popplerDataDir : POPPLER_DATADIR; into >> const char *dataRoot = (popplerDataDir && *popplerDataDir) ? popplerDataDir >> : POPPLER_DATADIR; Does that have any disadvantages? Andries On Sun, Feb 19, 2017 at 10:35:17PM +0100, Albert Astals Cid wrote: > This is not a bug in poppler, it does what we intented it to do. > > xpdf doesn't use poppler. > > If you have a xpdf that is using poppler someone is giving you something that > they call xpdf but it is not really xpdf. > > Please don't contact the poppler project about bugs in xpdf since it has > nothing to do with us. > > Best Regards, > Albert > > El diumenge, 19 de febrer de 2017, a les 20:16:13 CET, Andries E. Brouwer va > escriure: > > 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. 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.
