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