Notice: Undefined variable: name in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/pkgfuncs.inc.php on line 248

Package Details: gsdjvu 1.9-2

Git Clone URL: https://aur-dev.archlinux.org/gsdjvu.git (read-only)
Package Base: gsdjvu
Description: Very efficient way of converting PostScript and PDF documents into DjVu
Upstream URL: http://djvu.sourceforge.net/gsdjvu.html
Licenses: custom:unredistributable
Submitter: None
Maintainer: khampf
Last Packager: khampf
Votes: 16
Popularity: 0.000123
First Submitted: 2009-04-19 19:02
Last Updated: 2016-05-30 11:41

Latest Comments

1 2 Next › Last »

dc46and2 commented on 2016-05-25 23:18

It appears the ghostscript source has been moved to a new subdirectory. The correct URL is now: http://downloads.ghostscript.com/public/old-gs-releases/ghostscript-9.18.tar.bz2

khampf commented on 2016-03-07 09:25

Updated to gsdjvu 1.9 and ghostscript to 9.18

khampf commented on 2016-03-07 08:58

That bug refers to djvulibre (https://www.archlinux.org/packages/extra/x86_64/djvulibre/) not gdjvu. And it works for me with the current djvulibre and gsdjvu without any fixes:

DJVUDIGITAL --- DjVuLibre-3.5
GPL Ghostscript 9.14 (2014-03-26)
Copyright (C) 2014 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Page 2550x3300 ( fg-empty bg-color )
csepdjvu: 10222 bytes for page 1 (from stdin)

Nitsuga commented on 2016-03-07 02:57

Please update the ghostscript version in the PKGBUILD. Doing that solved this bug for me: https://sourceforge.net/p/djvu/bugs/272/

khampf commented on 2015-02-01 19:17

@lzlarryli fixed

lzlarryli commented on 2015-01-31 05:42

There seems to be some problem in the PKGBUILD. When I run it, it says:

==> ERROR: Missing package() function in ........../PKGBUILD

vinipsmaker commented on 2014-07-18 02:42

Gsdjvu 1.7 released, which works with the latest GhostScript, 9.14: https://sourceforge.net/p/djvu/bugs/238/#2bfa

khampf commented on 2012-08-15 10:55

@Jesin: On the contrary, we want to link to the installed libpng12 which includes headers (developement files). Why would we want to statically compile and include it in our binaries instead of sharing the same binary code with other software? And the part about "This usually is better because the resulting program benefits from the latest installed versions (including bug fix and security patches.)" refers to doing it this way, we do it the way the README recommends!

khampf commented on 2012-08-15 10:53

@Jesin: On the contrary, we want to link to the installed libpng12 which includes headers (developement files). Why would we want to statically compile and include it in our binaries instead of sharing the same binary code with other software?

Jesin commented on 2012-08-14 20:17

The README file states:
" If you do not provide any of the last three files,
jpegsrc, libpng and zlib, the building script will
attempt to use the system wide libraries.
This only works if the corresponding development files
are installed on your system. This usually is better
because the resulting program benefits from the latest
installed versions (including bug fix and security patches.)"
So I do not think you should include a dependency on libpng12.