pmaupin
commented
2 years ago Hello, Martin!
I have to admit to neglecting pdfrw lately, but it's possible that at some point I could be reenergized, and there certainly might be some room for collaboration. pdfrw used to be included in several linux distros, but then I think maybe it wasn't working with later versions of Python 3 (like maybe 3.8?) so they dropped it. Kind of snowballed from there.
pdfrw is my own original work for the most part, although: a) I think I might have taken some compression/decomp code from pypdf? Don't remember, the code should say. I certainly looked at other implementations; and b) I definitely added a couple of methods to make pdfrw compatible with pypdf for really simple things.
Having said that, and with the caveat that I haven't looked at either package in awhile, I will say that from what I remember (back when I was working on this):
1) pdfrw operates at a much lower level than pypdf, e.g. 2) pypdf is much more full featured, with, e.g. lots and lots of convenience methods, and 3) pdfrw is much faster than pypdf
If these things are still true (you could certainly try routing a couple of pdfs through each, and let me know if you have issues or what the heck the later python problem is, I dunno), and if the pypdf architecture would allow this, then it might (bearing in mind that I'm pulling all this out of my ass right now) make sense to use some of pdfrw as the underlying base of pypdf.
I probably won't have much time over the next few months, but I am always open to answering questions, and if you wanted to, for example merge the projects somehow, I don't have a real problem with that, other than that I would like the core functionality to remain clean and fast, and (from the outside looking in) it looks like a lot of code was merged into pypdf in a topsy-turvy fashion that emphasized getting something working over keeping it clean, maintainable, and fast.
Good luck and best regards, Pat
On Sat, Apr 9, 2022 at 9:15 AM Martin Thoma @.***> wrote:
I've recently became the maintainer of PyPDF2. While it will take me some time to increase test coverage, merge/close PRs, deal with Github tickets (issues), I'm looking forward to a new major release in which I can deprecate some parts.
One thing I like to do is to change the interface. It starts with simple things like reader.getNumPages() to become len(reader), changing the camelCase method names to snake_case, and adding type annotations.
I was wondering how big the difference between pdfrw is and how it's related to PyPDF2. Some things look super similar. Does pdfrw have its origins as a fork of PyPDF2?
Maybe it's possible to join efforts (I could imaging merging pdfrw into PyPDF2, creating a shared "base library" for both projects, or sharing parts of the test suite between both projects)
— Reply to this email directly, view it on GitHub https://github.com/pmaupin/pdfrw/issues/232, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASE2NUT74IYWTPJHO7XVBLVEGGJVANCNFSM5S7CWLIQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
abubelinha
I've recently became the maintainer of PyPDF2. While it will take me some time to increase test coverage, merge/close PRs, deal with Github tickets (issues), I'm looking forward to a new major release in which I can deprecate some parts.
One thing I like to do is to change the interface. It starts with simple things like
reader.getNumPages()to becomelen(reader), changing the camelCase method names to snake_case, and adding type annotations.I was wondering how big the difference between pdfrw is and how it's related to PyPDF2. Some things look super similar. Does pdfrw have its origins as a fork of PyPDF2?
Maybe it's possible to join efforts (I could imaging merging pdfrw into PyPDF2, creating a shared "base library" for both projects, or sharing parts of the test suite between both projects)