Bug#850163: xpdf/poppler miscommunication
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.
Reply to: