Bug#1023273: Old version is not working

The current maintainer of ocrmypdf and pikepdf is looking for a new maintainer, if someone else is able. On Sun, Nov 13, 2022 at 6:06 AM Anton Gladky wrote: > The newer 14 version of ocrmypdf is needed to suppor the > ghostscript 10. > > I have checked and can confirm, that 14.0.1 is working

Bug#980426: old pikepdf is blocking qpdf transition

Jay, the patch looks good to me. I did not try to run it, but it looks like it covers everything important. Sean, there is no license change to pikepdf. ocrmypdf did have the license change. If this is the holdup, ocrmypdf 10.x should work pikepdf 2.x with a trivial patch - the main change in

Bug#976092: ocrmypd fails autopkg tests in testing

This is almost certainly a problem with how Debian is compiling or linking ghostscript with libjbig2dec. This error would be reproducible with: gs -sDEVICE=pngmono -o out.png any_pdf_that_contains_a_jbig2_image.pdf Debian's test suite for ghostscript is just a simple smoke test, so ocrmypdf

Bug#962872: ocrmypdf: new major upstream version available

Sean and Rogério, It's easiest for everyone if the difference between upstream and packages is as small as possible, so I've been working on removing files that are problematic for Debian. In recent releases I have been removing all files that were previously in Files-Excluded, except for:

Bug#939044: ocrmypdf: autopkgtest not compatible with new pikepdf, ghostscript and/or pytest

Sean Whitton and I confirmed the issue still occurs with Ghostscript 9.28rc2. I reported the issue with Ghostscript here: https://bugs.ghostscript.com/show_bug.cgi?id=701552 On Fri, Sep 6, 2019 at 1:58 AM Jonas Smedegaard wrote: > > Quoting James R Barlow (2019-09-06 10:15:59) > > O

Bug#939044: ocrmypdf: autopkgtest not compatible with new pikepdf, ghostscript and/or pytest

On Thu, Sep 5, 2019 at 11:57 PM Jonas Smedegaard wrote: > > Quoting Sean Whitton (2019-09-06 06:20:47) > > On Sat 31 Aug 2019 at 03:58PM +02, Jonas Smedegaard wrote: > > > > > Possibly some of the other tools uses undocumented insecure > > > ghostscript calls which was recently removed. > > > > >

Bug#939530: ghostscript: 9.28rc1 regression interpreting valid PDFs

Package: ghostscript Version: 9.28~~rc1~dfsg-1 Severity: important Tags: upstream Dear Maintainer, 1. Ghostscript 9.28rc1 reports "Error reading content streams" when interpreting PDFs considered valid by Acrobat, qpdf, verapdf and previous versions of Ghostscript. 2. Ghostscript 9.28rc1

Bug#934035: ocrmypdf: FTBFS in stretch (failing tests)

The issue here is that we have an old version of ocrmypdf (4.3.5) with a backported version of Ghostscript (9.26) and the latter's behavior has changed in a way that breaks the test. I recommend disabling the test and documenting a caveat that certain metadata may not be preserved in output

Bug#930761: Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

I should mention that ocrmypdf no longer has an immediate use for PyMuPDF - I went the route of creating pikepdf, Python bindings for qpdf, and this is library is now in Debian thanks to Sean's work on packaging it. I don't think I would use PyMuPDF if it were available. pikepdf overlaps the core

Bug#908937: Info received (Bug#908937: ghostscript breaks ocrmypdf autopkgtest)

v6.2.4 is now available. On Sun, 16 Sep 2018 at 14:06 Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been

Bug#908937: ghostscript breaks ocrmypdf autopkgtest

Yes, I can backport the 7.x fixes to the 6.x release branch upstream. The result is a loss of the ability to set or retain PDF metadata fields other than pure ASCII. All characters that can't be represented in ASCII are getting replaced with '?'. (As far as I can tell, the Ghostscript commit

Bug#904185: img2pdf/0.3.0-1 appears to break ocrmypdf/6.2.2-2 autopkgtest: unexpected exit code

Fixed in upstream 6.2.3. ocrmypdf will reject images that contain an alpha channel if performing image to PDF conversion. On Sat, 21 Jul 2018 at 03:30 Johannes Schauer wrote: > Control: reassign -1 src:ocrmypdf > > Quoting Paul Gevers (2018-07-21 10:42:51) > > With a recent upload of img2pdf

Bug#903627: ocrmypdf: contains workaround for old version of python3-ruffus which should not be used with current python3-ruffus

I backported the fixes related to python3-ruffus 2.7, python 3.7 support, and a few other minor changes from 7.0.0. I released it just now as 6.2.2, so that should take care of it. Let me know if there are any further issues. On Thu, 12 Jul 2018 at 01:03 Sean Whitton wrote: > Package: ocrmypdf

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

Great to see the most recent test run passed, even if it is with liberal application of "expect failure". The Canonical powers that be should be appeased for the moment. I appreciate the last minute effort to get this, and Tesseract, into the next Ubuntu. Thinking about the failures, I suspect

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

hit...@spwhitton.name> wrote: > Hello, > > On Mon, Mar 26 2018, James R Barlow wrote: > > > Thanks for the information. That's a worryingly high wall to climb and > > I'm concerned about implications for other platforms as well. > > > > I would appreciate

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

ge 841404 -1 > > Dear James, > > On Mon, Mar 26 2018, James R. Barlow wrote: > > > In v6.0.0, which addresses and hopefully fixes #888917, I have > introduced a > > new dependency on PyMuPDF (Python bindings for MuPDF). Unfortunately > PyMuPDF > &g

Bug#888917: ocrmypdf fails to run it's testsuite

v6.0.0 should fix this issue, as it includes a cache that allows most OCR to be skipped.

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

Package: ocrmypdf Version: v6.0.0 Severity: serious Tags: newcomer Justification: fails to build from source (but built successfully in the past) Dear Sean, In v6.0.0, which addresses and hopefully fixes #888917, I have introduced a new dependency on PyMuPDF (Python bindings for MuPDF).

Bug#888917: ocrmypdf fails to run it's testsuite

t; control: retitle -1 Test suite failures > > Hello James, > > On Fri, Feb 02 2018, James R. Barlow wrote: > > > Do you think you could take a few minutes to identify which test is > > taking this long and report it? This may be an upstream bug, if some > > input

Bug#888917: ocrmypdf fails to run it's testsuite

Hello Sean, On Wed, 31 Jan 2018 22:06:42 -0700 Sean Whitton wrote: > I further suspect that the test suite took 30 seconds only because so > many tests failed early. In recent upstream versions, the test suite > has never finished running on my laptop after leaving it

Bug#888917: ocrmypdf fails to run it's testsuite

Upstream here. The reason the suite fails like that is that mandatory-for-testing dependencies were also removed. The test suite runs on Travis CI in 10-12 minutes. On Debian CI, 15 minutes. For comparison ffmpeg, another compute intensive CLI program, takes 10 minutes. This is an OCR program

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

I'm the ocrmypdf upstream author. First, be aware that the output of OCR and autorotate is cached in the test suite and the results are persisted between test cases and runs of the test suite in the tests/cache folder. The cache hit/miss check is not smart enough to pick up changes that aren't

Bug#813562: Test suite failure

, 20 Feb 2016 at 17:05 Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello, > > On Sat, Feb 20, 2016 at 03:27:00AM +, James R Barlow wrote: > > Thanks for your help. Output order is due to multiprocessing. > > No problem. > > > That nailed it. tesseract 3

Bug#815391: Ghostscript 9.16 (debian stretch) not linked against libopenjpeg

Package: libgs9 Version: 9.16~dfsg-2.1 When asked to perform any operation on a PDF containing JPEG2000 (/JPXDecode) images, Ghostscript displays the following: $ gs -dBATCH -dQUIET -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=_.pdf anyjpeg2000.pdf ERROR: Unable to process JPXDecode data.

Bug#813562: Test suite failure

Script confidence: 45.33 On Fri, Feb 19, 2016 at 16:28 Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello, > > On Fri, Feb 19, 2016 at 10:45:51PM +, James R Barlow wrote: > > In any case, could you try running this: > > ocrmypdf --rotate-pages tests/res

Bug#813562: Test suite failure

12:04 Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello, > > On Fri, Feb 19, 2016 at 07:11:32AM +, James R Barlow wrote: > > What version of leptonica is installed? > > tesseract --version will report this. > > From within my Sid chroot: > >

Bug#813562: Test suite failure

I have seen a similar problem. What version of leptonica is installed? tesseract --version will report this. Also what's the file name for liblept? On Thu, Feb 18, 2016 at 21:29 Sean Whitton wrote: > Dear James, > > OCRmyPDF's test suite is currently failing under a

Bug#813562: Copyright clarification of some test resources files

Yes, I'll tag a release when it's ready to go. On Tue, 16 Feb 2016 at 17:26 Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello, > > On Tue, Feb 16, 2016 at 01:55:47PM +, James R Barlow wrote: > > I updated my tree, eliminating one file whose status I couldn't >

Bug#813562: Copyright clarification of some test resources files

I updated my tree, eliminating one file whose status I couldn't determine, replacing another with an equivalent free file and documenting the rest. The file has also been renamed to README so that Github shows it automatically. https://github.com/jbarlow83/OCRmyPDF/tree/develop/tests/resources

Bug#813562: Project maintainer here

pwhitton.name> wrote: > Hello, > > Thank you for your e-mail. > > On Sat, Feb 13, 2016 at 01:35:10AM +, James R Barlow wrote: > > On Fri, 12 Feb 2016 at 17:05 Sean Whitton <spwhit...@spwhitton.name> > wrote: > > I have a non-packaging question that I'

Bug#813562: Project maintainer here

Let me know if you'd like to see any changes to help with packaging. If you are packaging around 3.1.1, versions older than 3.2.1 are incompatible with the recently released img2pdf 0.2.0; they require 0.1.5, and they do not enforce this dependency on their own. If you try to install any of them

Bug#813562: Project maintainer here

On Fri, 12 Feb 2016 at 17:05 Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello, > > On Fri, Feb 12, 2016 at 03:23:39AM -0800, James R Barlow wrote: > > Let me know if you'd like to see any changes to help with packaging. > > Thank you for your input, and for