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
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
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 othe
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
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
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
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 situ
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.
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
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).
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
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 por
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
Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
ret
13 matches
Mail list logo