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
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
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
[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,
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
Processing control commands:
> reassign -1 wnpp
Bug #894068 [ocrmypdf] ocrmypdf: New dependency on PyMuPDF for v6.0.0
Bug reassigned from package 'ocrmypdf' to 'wnpp'.
No longer marked as found in versions v6.0.0.
Ignoring request to alter fixed versions of bug #894068 to the same values
previous
9 matches
Mail list logo
