Hi,
> On Wed, May 14, 2008, Junichi Uekawa wrote:
> > xpdf-japanese installs CMAP files in
> > /usr/share/fonts/cmap/adobe-japan1 etc, but libpoppler looks at
> > /usr/share/poppler.
> >
> > I need to install the following symlinks in order to use the adobe
> > CMAP files.
> >
> > $ ls -l /usr/share/poppler/cidToUnicode/Adobe-Japan1
> > lrwxrwxrwx 1 root root 34 2008-01-18 19:53 Adobe-Japan1 ->
> > /usr/share/fonts/cmap/adobe-japan1
> >
> > $ ls -l /usr/share/poppler/cMap/
> > lrwxrwxrwx 1 root root 50 2008-01-18 19:53
> > /usr/share/poppler/cidToUnicode/Adobe-Japan1 ->
> > /usr/share/xpdf/japanese/Adobe-Japan1.cidToUnicode
> >
> > Please either make poppler look at the old location or install some
> > kind of symlinking.
>
> Is this a regression from previous poppler versions?
Yup. It used to use xpdf resources in etch.
I wondered why this is the case and looked a bit closer into the problem.
etch poppler used to look at /etc/xpdfrc for configuration, thus it
re-used xpdf configuration for CID etc.
sid poppler has the paths hard-coded somewhere.
$ strings /usr/lib/libpoppler.so | grep usr
/usr/share/poppler/unicodeMap
/usr/share/poppler/cMap
/usr/share/poppler/nameToUnicode
/usr/share/poppler/cidToUnicode
These are apparently configured in poppler/GlobalParams.cc,
GlobalParams::scanEncodingDirs()
It looks as if it's a trivial task to add the other dirs and make it
scan there also for backwards portability.
For full compatibility, parsing of xpdfrc is necessary, but that's
going backwards looking at poppler changelog.
There are probably 3 ways to fix this problem, and I think 1 has the least
impact.
1. make poppler look into the old paths again
2. make xpdf-japanese/xpdf-* provide the files in the new path (hardlinked or
symlinked)
3. get poppler-data into NEW (users will have to install packages with
duplicate data).
regards,
junichi
--
[EMAIL PROTECTED],netfort.gr.jp} Debian Project
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
