Re: FWD: Re: Update textproc/xpdf
Hi,
On Mon, Oct 23, 2017 at 06:05:08PM +0200, Alexander Bluhm wrote:
> On Sun, Oct 22, 2017 at 06:26:15PM +0200, Matthias Kilian wrote:
> > I'll try it later this evening. But I always wondered why one wants
> > to print a pdf out of a pdf *viewer* ;-)
>
> I have always used xpdf to convert the wanted pages to postscript
> and send them with lpr to my printer. You can even type "ssh
> myprinthost lpr" in the command field and do it remotely.
>
> What is wrong with that workflow? Is there a better way to print
> pages of pdf on a postscript printer? ghostview?
Did you miss the smiley above?
Anyway, here's an updated diff, with some suggestions included
(remove USE_GMAKE, add rdeps/bdeps for jpeg, png, tiff, allthough
tiff export still doesn't work).
For printing (using DXPDFWIDGET_PRINTING=true), the cmake magic
fails to add -L${LOCALBASE}/lib when linking the xpdf executable.
I really need some help from a cmake expert here (CMAKE_LIBRARY_PATH
doesn't help).
And for tiff export, all I see (after some stat(2) and lstat(2) calls)
ist this:
31413 xpdf CALL
open(0x8305c186498,0x10601,0666)
31413 xpdf NAMI "/home/kili/apu2/foo.tiff"
31413 xpdf RET open 14/0xe
31413 xpdf CALL fcntl(14,F_SETFD,FD_CLOEXEC)
31413 xpdf RET fcntl 0
31413 xpdf CALL close(14)
31413 xpdf RET close 0
31413 xpdf CALL unlink(0x8305c186498)
31413 xpdf NAMI "/home/kili/apu2/foo.tiff"
31413 xpdf RET unlink 0
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.89
diff -u -p -r1.89 Makefile
--- Makefile26 Jul 2017 22:45:31 - 1.89
+++ Makefile23 Oct 2017 20:18:11 -
@@ -2,33 +2,47 @@
COMMENT= PDF viewer for X11
-DISTNAME= xpdf-3.04
+DISTNAME= xpdf-4.00
CATEGORIES=textproc x11
-REVISION= 2
-MASTER_SITES= ftp://ftp.foolabs.com/pub/xpdf/ \
- http://mirror.ctan.org/support/xpdf/
+MASTER_SITES= https://www.xpdfreader.com/dl/
-HOMEPAGE= http://www.foolabs.com/xpdf/
+HOMEPAGE= https://www.xpdfreader.com/
# GPLv2 only or GPLv3 only or both (at our choice)
PERMIT_PACKAGE_CDROM= Yes
-LIB_DEPENDS+= graphics/png x11/motif
-USE_GMAKE= Yes
-CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--enable-multithreaded \
- --without-Sgm-library \
- --without-libpaper-library
-
-CONFIGURE_ENV= CPPFLAGS='-I${X11BASE}/include/freetype2 -I${X11BASE}/include
-I${LOCALBASE}/include -DLOCALBASE="\"${LOCALBASE}\""' \
- LDFLAGS="-L${X11BASE}/lib -L${LOCALBASE}/lib -lm -lz"
-MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
+MODULES= devel/cmake \
+ X11/qt5
RUN_DEPENDS= print/ghostscript/gnu-fonts
-WANTLIB= ICE SM X11 Xext Xpm Xt freetype Xm \
- c m png pthread ${COMPILER_LIBCXX} z
+# Add jpeg, png, tiff as rdep and bdep so cmake always pick them up and
+# xpdf is able to export to those formats. Not strictly needed for jpeg
+# and png, because they are pulled in by qt and its dependencies, but
+# better be explicit here.
+# But note that tiff export doesn't work.
+RUN_DEPENDS += graphics/jpeg \
+ graphics/png \
+ graphics/tiff
+
+BUILD_DEPENDS +=graphics/jpeg \
+ graphics/png \
+ graphics/tiff
+
+# Don't pick up libpaper -- the build currently fails to link against
+# it.
+CONFIGURE_ARGS += -DHAVE_PAPER_H=0
+
+# XXX
+# Doesn't work, neither with -DCMAKE_LIBRARY_PATH=${LOCALBASE}/lib nor
+# with CMAKE_LIBRARY_PATH=${LOCALBASE}/lib in the environment.
+# CONFIGURE_ARGS +=-DXPDFWIDGET_PRINTING=true
+
+CXXFLAGS+= -DLOCALBASE=\\\"${LOCALBASE}\\\"
+
+WANTLIB= Qt5Core Qt5Gui Qt5Widgets freetype c m png pthread \
+ ${COMPILER_LIBCXX} z
NO_TEST= Yes
@@ -37,13 +51,9 @@ post-install:
${INSTALL_DATA} ${WRKSRC}/doc/sample-xpdfrc \
${PREFIX}/share/examples/xpdf/xpdfrc
# already in poppler-utils
-.for i in pdffonts pdfimages pdfinfo pdftoppm pdftops pdftotext
+.for i in pdffonts pdfimages pdfinfo pdftohtml pdftoppm pdftops pdftotext
rm ${PREFIX}/man/man1/$i.1
rm ${PREFIX}/bin/$i
.endfor
-# forgotten in Makefile.in (there's also a pdfthtml, but it conflicts
-# with poppler-utils):
- ${INSTALL_PROGRAM} ${WRKBUILD}/xpdf/pdftopng ${PREFIX}/bin
- ${INSTALL_MAN} ${WRKSRC}/doc/pdftopng.1 ${PREFIX}/man/man1
.include
Index: distinfo
===
RCS file: /cvs/ports/textproc/xpdf/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo8 Jun 2014 18:56:33 - 1.18
+++ distinfo23 Oct 2017 20:18:11 -
@@ -1,2 +1,2 @@
-SHA256 (xpdf-3.04.tar.gz) = ETkMdHM6vLJiqspNtocQ8T///UK/4qCGGl38kSspd+U=
-SIZE
Re: FWD: Re: Update textproc/xpdf
On Mon, Oct 23, 2017 at 06:05:08PM +0200, Alexander Bluhm wrote: > On Sun, Oct 22, 2017 at 06:26:15PM +0200, Matthias Kilian wrote: > > I'll try it later this evening. But I always wondered why one wants > > to print a pdf out of a pdf *viewer* ;-) > > I have always used xpdf to convert the wanted pages to postscript > and send them with lpr to my printer. You can even type "ssh > myprinthost lpr" in the command field and do it remotely. > > What is wrong with that workflow? Is there a better way to print > pages of pdf on a postscript printer? ghostview? Cups should be happy to do so as well... just saying
Re: FWD: Re: Update textproc/xpdf
On Sun, Oct 22, 2017 at 06:26:15PM +0200, Matthias Kilian wrote: > I'll try it later this evening. But I always wondered why one wants > to print a pdf out of a pdf *viewer* ;-) I have always used xpdf to convert the wanted pages to postscript and send them with lpr to my printer. You can even type "ssh myprinthost lpr" in the command field and do it remotely. What is wrong with that workflow? Is there a better way to print pages of pdf on a postscript printer? ghostview? Does every postscript printer understand pdf natively? bluhm
Re: FWD: Re: Update textproc/xpdf
On 2017/10/22 18:26, Matthias Kilian wrote:
> 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 use it when I want to print just one page of a longer pdf, there are
other ways to do that, but this is nice and easy (much simpler than looking
up the option in cups version of lpr(1) for example).
> > > 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.
Any idea what's happening with jpeg? It's not linked either but has the
cmake check and there's code which looks like it uses it ..
Re: FWD: Re: Update textproc/xpdf
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
Re: FWD: Re: Update textproc/xpdf
On 2017/10/22 16:51, Ingo Schwarze wrote: > Reposting here, maybe i should have done that in the first place > to avoid duplicate work, sorry sthen@ and aja@... Thanks :) > It does spew crap to stderr that i didn't notice with previous > versions, but i may have missed it. Probably such splatter is > to be expected with "modern" software (sigh). > > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to > '/tmp/runtime-schwarze' > libGL error: failed to open drm device: Permission denied > libGL error: failed to load driver: i965 Sounds "normal" to me. Also has the "normal" thing that I see with a lot of software using Qt where if I move the pointer out of a pop-up window it warps back to the middle of the window (possibly something to do with cwm). 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. > Looking at the build log, this looks somewhat strange: > > ===> Applying OpenBSD patch patch-xpdf_GlobalParams_cc > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |$OpenBSD: patch-xpdf_GlobalParams_cc,v 1.4 2015/04/06 21:05:07 ajacoutot > Exp $ > |--- xpdf/GlobalParams.cc.orig Wed May 28 20:50:50 2014 > |+++ xpdf/GlobalParams.cc Fri May 30 14:27:13 2014 > -- > Patching file xpdf/GlobalParams.cc using Plan A... > Hunk #1 succeeded at 103 (offset -17 lines). > done > > Does the "offset -17 lines" mean that the patch should be regenerated? > Same for patch-xpdf_XRef_cc. Yes. > Why do you list png explicitly in LIB_DEPENDS, but not jpeg? > Given that the only other direct lib dependency, qtbase, requires > both jpeg and png directly and that the xpdf cmake run explicitly > tests for both, what is the difference? > > 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..
