Hi,
On Sun, Oct 22, 2017 at 05:03:50PM +0100, Stuart Henderson wrote:
> It seems to have lost the ability to print. There's a build flag
> (-DXPDFWIDGET_PRINTING=true) which might fix that, but I haven't got
> it to build yet.
I'll try it later this evening. But I always wondered why one wants
to print a pdf out of a pdf *viewer* ;-)
> > I see this in my output:
> >
> > -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8")
> >
> > but:
> >
> > $ pkg_info -S xpdf
> > Information for inst:xpdf-4.00
> > Signature:
> > xpdf-4.00,0,@ghostscript-fonts-8.11p3,@png-1.6.31,@qtbase-5.9.1p4,Qt5Core.2.1,Qt5Gui.2.1,Qt5Widgets.2.1,c++.1.0,c++abi.0.0,c.90.0,freetype.28.1,m.10.0,png.17.4,pthread.24.0,z.5.0
> >
> > No tiff in there. Any idea what is going on?
> >
> > Maybe that's all harmless, but who knows, i thought i'd better mention it.
>
> Something funny going on there indeed.. Possibly not helped by Qt's
> propensity for dlopen()'ing things..
It really doesn't use libtiff by itself:
[kili@knecht:xpdf-4.00]$ find . -type f| xargs grep -i tiff
./cmake-config.txt:#--- look for libtiff
./cmake-config.txt:find_package(TIFF)
./xpdf/Stream.cc: default: // no predictor or TIFF
predictor
./xpdf/Stream.cc: // apply TIFF (component) predictor
./xpdf-qt/XpdfViewer.cc: { "TIFF", "TIFF files (*.tiff)", "TIFF" }
./CHANGES:Fixed a bug in end-of-stream detection with the TIFF predictor.
./CHANGES:Fixed a bug in the TIFF image component predictor which shows up with
./CHANGES:The TIFF predictor code for the 1-bit-per-pixel case was broken.
xpdf-3.04 didn't use libtiff, either.
Ciao,
Kili
