[Poppler-bugs] xpdf/poppler miscommunication

[Andries E. Brouwer]

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.