Re: UPDATE: xpdf-4.04
07.02.2023 09:35, Stuart Henderson пишет: > I have no objections to updating textproc/xpdf to 4.x as long as the > existing 3.x is reimported (I'd prefer a different pkgpath and binary > name, e.g. textproc/xpdf3, so the two can coexist easily). +1
Re: UPDATE: xpdf-4.04
On Tue, Feb 07, 2023 at 09:35:05AM +, Stuart Henderson wrote: > > $ lpr doc.pdf > > That works if you want the whole file :) Good point. I hadn't thought of that. > And there are other ways to get subsets, but if you want to open the > pdf, quickly identify the page numbers of interest, and print just > those, the workflow in xpdf 3 is very convenient. Yeah, I can never remember the options to those PDF splitters. -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: UPDATE: xpdf-4.04
On 2023/02/07 09:28, Edd Barrett wrote: > On Mon, Feb 06, 2023 at 06:35:38PM +, Stuart Henderson wrote: > > It doesn't print though. > > That used to annoy me too, until I realised that I can just do (with cups): > > $ lpr doc.pdf That works if you want the whole file :) And there are other ways to get subsets, but if you want to open the pdf, quickly identify the page numbers of interest, and print just those, the workflow in xpdf 3 is very convenient. I have no objections to updating textproc/xpdf to 4.x as long as the existing 3.x is reimported (I'd prefer a different pkgpath and binary name, e.g. textproc/xpdf3, so the two can coexist easily).
Re: UPDATE: xpdf-4.04
On Mon, Feb 06, 2023 at 06:35:38PM +, Stuart Henderson wrote: > It doesn't print though. That used to annoy me too, until I realised that I can just do (with cups): $ lpr doc.pdf -- Best Regards Edd Barrett https://www.theunixzoo.co.uk
Re: UPDATE: xpdf-4.04
Hi, On Mon, Feb 06, 2023 at 03:24:03PM +0100, Christian Weisgerber wrote: > Klemens Nanni: > > > > Should xpdf 3 be kept around? > > > > Compared to mupdf, though, xpdf 3 has this nice chapter view and is > > great for navigating specifications and such. > > FWIW, FreeBSD has kept an xpdf3 port around. > > I also use xpdf3 as my primary PDF viewer/printer and I'm not happy > with the situation. I'd like if xpdf3 could be kept for those preferring it. IIRC, xpdf4 not only wasn't incapable of printing (which was the reason I backed it out), but also was much slower then xpdf3. > > I wouldn't mind keeping a copy of old xpdf if it benefits users and > > doesn't turn into an unmaintained port which will eventually lack > > critical fixes or so. > > Unfortunately that is already the case as upstream has moved on to > the Qt version. The best solution for something like xpdf3 would be to largely rewrite it to use poppler instead of its own pdf engine -- I know, our poppler is outdated, too, because of lack of time on my side to fix all the breakage in depending ports (since about one year ago). > Back in late 2021, there was a kerfuffle about an Apple security > vulnerability in some crufty JBIG2 code. Security analyses at the > time mentioned that the vulnerable code had come from xpdf, but it > took about a year for a fix to trickle back to xpdf3. Although, > it had taken like half a year for a new xpdf4 release, too. Upstream often was a little bit slow ;-) Ciao, Kil
Re: UPDATE: xpdf-4.04
On 2023/02/06 11:24, Klemens Nanni wrote: > 06.02.2023 10:03, Theo Buehler пишет: > > I always thought of xpdf as a relatively lightweight pdf viewer. This > > diff makes it depend on Qt stuff which is all but lightweight. > > > > What are alternatives on older architectures? > > mupdf should be there, which is pretty small and decent. It doesn't print though.
Re: UPDATE: xpdf-4.04
Klemens Nanni: > > Should xpdf 3 be kept around? > > Compared to mupdf, though, xpdf 3 has this nice chapter view and is > great for navigating specifications and such. FWIW, FreeBSD has kept an xpdf3 port around. I also use xpdf3 as my primary PDF viewer/printer and I'm not happy with the situation. > I wouldn't mind keeping a copy of old xpdf if it benefits users and > doesn't turn into an unmaintained port which will eventually lack > critical fixes or so. Unfortunately that is already the case as upstream has moved on to the Qt version. Back in late 2021, there was a kerfuffle about an Apple security vulnerability in some crufty JBIG2 code. Security analyses at the time mentioned that the vulnerable code had come from xpdf, but it took about a year for a fix to trickle back to xpdf3. Although, it had taken like half a year for a new xpdf4 release, too. (I remember that I looked for an xpdf fix already when the Apple thing was in the news but couldn't find one.) -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: UPDATE: xpdf-4.04
On Mon Feb 06, 2023 at 11:24:38AM +, Klemens Nanni wrote: > > I wouldn't mind keeping a copy of old xpdf if it benefits users and > doesn't turn into an unmaintained port which will eventually lack > critical fixes or so. > That would also be my concern.
Re: UPDATE: xpdf-4.04
06.02.2023 10:03, Theo Buehler пишет: > I always thought of xpdf as a relatively lightweight pdf viewer. This > diff makes it depend on Qt stuff which is all but lightweight. > > What are alternatives on older architectures? mupdf should be there, which is pretty small and decent. > Should xpdf 3 be kept around? Compared to mupdf, though, xpdf 3 has this nice chapter view and is great for navigating specifications and such. No idea about the printing bits. I wouldn't mind keeping a copy of old xpdf if it benefits users and doesn't turn into an unmaintained port which will eventually lack critical fixes or so.
Re: UPDATE: xpdf-4.04
On Mon, Feb 06, 2023 at 10:45:13AM +0100, Omar Polo wrote: > On 2023/02/05 20:38:58 +0100, Rafael Sadowski wrote: > > On Sun Feb 05, 2023 at 08:35:38PM +0100, Rafael Sadowski wrote: > > > Update diff xpdf-4.04. > > > > > > - Upstream switched to camke > > > - Prefer Qt5 instead of Qt6 (default). The printer code not compile with > > > Qt6.4. > > > > > > Tested on amd64. OK? > > > > > > Rafael > > > > > > > Repeat afte me, first portcheck then send to ports@. New diff without > > trailing whitespace. > > it's missing `z' in WANTLIBs ;-) > > xpdf-4.04v0(textproc/xpdf): > Missing: z.7 (/usr/local/bin/pdftopng) (system lib) > WANTLIB += z > > otherwise it builds and seems to work fine (only tested the viewing of > pdfs, not printing). > > ok op@ > I always thought of xpdf as a relatively lightweight pdf viewer. This diff makes it depend on Qt stuff which is all but lightweight. What are alternatives on older architectures? Should xpdf 3 be kept around?
Re: UPDATE: xpdf-4.04
On 2023/02/05 20:38:58 +0100, Rafael Sadowski wrote: > On Sun Feb 05, 2023 at 08:35:38PM +0100, Rafael Sadowski wrote: > > Update diff xpdf-4.04. > > > > - Upstream switched to camke > > - Prefer Qt5 instead of Qt6 (default). The printer code not compile with > > Qt6.4. > > > > Tested on amd64. OK? > > > > Rafael > > > > Repeat afte me, first portcheck then send to ports@. New diff without > trailing whitespace. it's missing `z' in WANTLIBs ;-) xpdf-4.04v0(textproc/xpdf): Missing: z.7 (/usr/local/bin/pdftopng) (system lib) WANTLIB += z otherwise it builds and seems to work fine (only tested the viewing of pdfs, not printing). ok op@
Re: UPDATE: xpdf-4.04
On Sun Feb 05, 2023 at 08:35:38PM +0100, Rafael Sadowski wrote:
> Update diff xpdf-4.04.
>
> - Upstream switched to camke
> - Prefer Qt5 instead of Qt6 (default). The printer code not compile with
> Qt6.4.
>
> Tested on amd64. OK?
>
> Rafael
>
Repeat afte me, first portcheck then send to ports@. New diff without
trailing whitespace.
Rafael
Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.96
diff -u -p -u -p -r1.96 Makefile
--- Makefile24 Aug 2022 08:00:05 - 1.96
+++ Makefile5 Feb 2023 19:37:23 -
@@ -1,49 +1,47 @@
COMMENT= PDF viewer for X11
-DISTNAME= xpdf-3.04
+DISTNAME= xpdf-4.04
CATEGORIES=textproc x11
EPOCH= 0
-REVISION= 2
-
-MASTER_SITES= https://xpdfreader-dl.s3.amazonaws.com/old/
HOMEPAGE= https://www.xpdfreader.com/
+MASTER_SITES= https://dl.xpdfreader.com/
+
# GPLv2 only or GPLv3 only or both (at our choice)
PERMIT_PACKAGE=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'
+WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Network Qt5PrintSupport
+WANTLIB += Qt5Widgets c cups fontconfig freetype m paper png
+
+MODULES= devel/cmake \
+ x11/qt5
+
+LIB_DEPENDS+= graphics/png \
+ print/libpaper
RUN_DEPENDS= print/ghostscript/gnu-fonts
-WANTLIB= ICE SM X11 Xext Xpm Xt freetype Xm \
- c m png pthread ${COMPILER_LIBCXX} z
+CXXFLAGS +=-I${X11BASE}/include -I${LOCALBASE}/include
+MODCMAKE_LDFLAGS = -L${X11BASE}/lib -L${LOCALBASE}/lib
-COMPILER = base-clang ports-gcc base-gcc
+CONFIGURE_ARGS=-DOPI_SUPPORT=ON \
+ -DXPDFWIDGET_PRINTING=ON \
+ -DSYSTEM_XPDFRC=/etc/xpdfrc
NO_TEST= Yes
+pre-configure:
+ ${SUBST_CMD} ${WRKDIST}/xpdf/GlobalParams.cc
+
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/xpdf
${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 pdftoppm pdftops pdftotext pdftohtml
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.20
diff -u -p -u -p -r1.20 distinfo
--- distinfo8 Nov 2017 18:30:24 - 1.20
+++ distinfo5 Feb 2023 19:37:23 -
@@ -1,2 +1,2 @@
-SHA256 (xpdf-3.04.tar.gz) = ETkMdHM6vLJiqspNtocQ8T///UK/4qCGGl38kSspd+U=
-SIZE (xpdf-3.04.tar.gz) = 825519
+SHA256 (xpdf-4.04.tar.gz) = Y84j/L92BI9STEC+R5rDhA16LLrbbR4GRup3kmZWut4=
+SIZE (xpdf-4.04.tar.gz) = 969535
Index: patches/patch-Makefile_in
===
RCS file: patches/patch-Makefile_in
diff -N patches/patch-Makefile_in
--- patches/patch-Makefile_in 11 Mar 2022 20:03:36 - 1.5
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,18 +0,0 @@
Makefile.in.orig Mon Aug 15 23:08:52 2011
-+++ Makefile.inThu Aug 18 21:10:22 2011
-@@ -102,13 +102,8 @@ install: dummy
- $(INSTALL_DATA) $(srcdir)/doc/pdfimages.1
$(DESTDIR)@mandir@/man1/pdfimages.1
- -mkdir -p $(DESTDIR)@mandir@/man5
- $(INSTALL_DATA) $(srcdir)/doc/xpdfrc.5 $(DESTDIR)@mandir@/man5/xpdfrc.5
-- -mkdir -p $(DESTDIR)@sysconfdir@
-- @if test ! -f $(DESTDIR)@sysconfdir@/xpdfrc; then \
-- echo "$(INSTALL_DATA) $(srcdir)/doc/sample-xpdfrc
$(DESTDIR)@sysconfdir@/xpdfrc"; \
-- $(INSTALL_DATA) $(srcdir)/doc/sample-xpdfrc
$(DESTDIR)@sysconfdir@/xpdfrc; \
-- else \
-- echo "# not overwriting the existing
$(DESTDIR)@sysconfdir@/xpdfrc"; \
-- fi
-+ -mkdir -p $(PREFIX)/share/examples/xpdf
-+ $(INSTALL_DATA) $(srcdir)/doc/sample-xpdfrc
$(PREFIX)/share/examples/xpdf/xpdfrc
-
- clean:
- -cd goo; $(MAKE) clean
Index: patches/patch-cmake-config_txt
===
RCS file: patches/patch-cmake-config_txt
diff -N patches/patch-cmake-config_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++
