Hello,
On Thu 20 Jun 2019 at 08:34AM +02, Johannes Schauer wrote:
> We have a similar issue but a less severe one because this is only one package
> and not a whole ecosystem of them. Since the required tooling is currently
> missing, I guess any maintainer of PyMuPDF would need to closely follow
Hello,
On Wed 19 Jun 2019 at 11:42PM -07, James R Barlow wrote:
> 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
> t
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
o
Hi Sean,
Quoting Sean Whitton (2019-06-20 07:28:12)
> [updating CC to point to the newly-filed RFP]
thank you!
> Thank you again for looking into this.
Incidentally I'm currently writing a tool that needs PyMuPDF so I'll probably
spend a bit more time on this. ;)
> On Sat 08 Jun 2019 at 09:52p
[updating CC to point to the newly-filed RFP]
Hello Johannes,
Thank you again for looking into this.
On Sat 08 Jun 2019 at 09:52pm +0200, Johannes Schauer wrote:
> after my struggles in #930212 I now figured out how to compile stuff against
> the static library in libmupdf-dev. As a result I ma
Hello,
On Fri, May 18 2018, James R. Barlow wrote:
> I ended up deciding to remove PyMuPDF (apart from optional tests in
> the test suite, anyway) from the next major release of ocrmypdf - I'll
> still need your support with some new dependencies, but I think I've
> found a solution that should m
Hello,
On Sat, Mar 31 2018, James R Barlow wrote:
> Hello Sean,
>
> As promised ocrmypdf v6.1.2 makes pymupdf optional but recommended. My
> continuous integration tests check with and without pymupdf.
>
> The only major regression without pymupdf is that with all of:
> 1) an input file containin
Hello Sean,
As promised ocrmypdf v6.1.2 makes pymupdf optional but recommended. My
continuous integration tests check with and without pymupdf.
The only major regression without pymupdf is that with all of:
1) an input file containing a mix of scanned and born digital files
2) --skip-text (not de
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 if you can see about getting an exception, but I
> think I will change PyMuPDF to an op
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 if you can see about getting an exception, but I think I
will change PyMuPDF to an optional but recommended dependency fairly soon.
I haven't made
control: reassign -1 wnpp
control: forcemerge 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
> isn't available in Debia
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). Unfortun
12 matches
Mail list logo
