Search Criteria
Package Details: pdfbeads 1.1.3-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/pdfbeads.git (read-only, click to copy) |
---|---|
Package Base: | pdfbeads |
Description: | A small utility written in Ruby which takes scanned page images and converts them into a single PDF file |
Upstream URL: | https://github.com/akryukov/pdfbeads |
Licenses: | GPL |
Submitter: | None |
Maintainer: | dark-saber |
Last Packager: | dark-saber |
Votes: | 4 |
Popularity: | 0.000000 |
First Submitted: | 2012-01-29 19:23 (UTC) |
Last Updated: | 2022-07-21 18:44 (UTC) |
Dependencies (9)
- imagemagick (imagemagick-gitAUR, imagemagick-fullAUR, imagemagick-full-gitAUR)
- openjpeg2 (openjpeg-gitAUR)
- ruby
- ruby-nokogiri
- ruby-pdf-reader
- ruby-rdoc
- ruby-rmagickAUR
- jbig2encAUR (jbig2enc-gitAUR, jbig2encAUR) (optional) – for better JPEG2000 compression
- ruby-iconv (optional)
Latest Comments
1 2 3 Next › Last »
groundstate commented on 2021-04-24 16:47 (UTC)
This package builds as-is, but the executable fails to run. If ruby-nokogiri and ruby-iconv are installed prior to building this package, the executable runs correctly. Therefore, I think ruby-nokogiri and ruby-iconv should be added as either build dependencies or run dependencies, or both, depending on how ruby works. Thanks!
mwillems commented on 2019-07-27 17:06 (UTC)
pdfbeads is now failing to include color images in the produced pdfs. Specifically, pdfbeads runs to completion producing no errors or unusual output, and produces a pdf, but any pages with color images appear as solid black panels in the resulting pdf. Purely black and white pages using jbig compression appear normally, but any color image presents as a black square.
I hadn't run pdfbeads in a few months, but the issue was introduced sometime since May (pdfbeads was working perfectly at that point). That points to a likely issue with a dependency like imagmagick or ruby-rmagick since pdfbeads itself hasn't changed. My source images are tifs generated by scantailor, but any image file I tested seems to produce the same result. If anyone can confirm or suggest avenues for diagnostic testing, I'd appreciate it.
mwillems commented on 2019-02-27 18:43 (UTC)
Thank you for the your quick response. I just did a few test runs, and pdfbeads seemed to be working correctly with the latest rmagick, at least for the functions that I use.
Thanks again!
dark-saber commented on 2019-02-27 10:29 (UTC) (edited on 2019-02-27 10:35 (UTC) by dark-saber)
mwillems:
Thank you! I'm going back to the boredland's fork as it seems to work for me with rmagick 3.0 (if something is still broken, tell me).
And I'll check if it's possible to make this new 1.1.2 fork work with rmagick 3.0. But if some functionality is broken, it won't make it here.
mwillems commented on 2019-02-27 01:56 (UTC)
It looks like the latest update to ruby-rmagick causes pdfbeads to error out immediately due to version checking. Not sure if its a simple version test issue or if pdfbeads actually relies on prior behavior in ruby-rmagick.
mwillems commented on 2018-04-16 14:49 (UTC)
The tiffs were generated by scantailor. It looks like there's a recently closed issue on the imagemagick tracker about this precise TIFF error, and the devs say it's fixed in the next release. I'll wait until then to report as it's likely the same issue. Thanks for steering me in the right direction.
dark-saber commented on 2018-04-16 13:13 (UTC)
mwillems:
Yes, the deprecation lines are irrelevant for now. I'm using pdfbeads as a part of dpsprep djvu->pdf conversion routine, and it seems to produce good tiffs, but I've found some tiffs from other people that lead to the same error. Unfortunately, I don't know how these images were generated.
I think this issue should be reported upstream to ImageMagick developers (https://github.com/ImageMagick/ImageMagick/issues), preferably with an example of faulty tiff and maybe with some information on previous steps on those tiffs (conversion, generation?). Devs say they've added additional image validity checks in the last few releases, so the report would help to determine if there's a fault in their checks or some previous step of your routine corrupts the image's metadata. Some people have already opened issues about regressions in newer releases which may or may not be related.
mwillems commented on 2018-04-16 00:48 (UTC) (edited on 2018-04-16 00:56 (UTC) by mwillems)
This command fails:
pdfbeads *.tif -b JPG -B 36 -f -o book.pdf
The exact same command works perfectly on the exact same files with imagemagick-6.9.9.39-2 (and prior to that for more than a year in a script). I tried reinstalling ruby-rmagick, but that didn't help.
Here's the error it throws (below). I see the first two lines (about deprecation) even when things are working lately; they don't seem to actually affect functionality. From the traceback down only shows up since imagemagick-6.9.9.40, and of course pdfbeads quits immediately after the traceback without processing the files:
dark-saber commented on 2018-04-10 10:19 (UTC)
mwillems:
Sorry for the late answer. Could you please provide an example of failing command? I had got some warnings, but they were fixed by reinstalling ruby-nokogiri, besides that, pdfbeads works on my test tasks.
mwillems commented on 2018-03-31 00:31 (UTC)
This was working well until the latest imagemagick6 update, and it is now erroring out immediately. Reverting to the prior imagemagick6 version fixes it.
1 2 3 Next › Last »