If so, it's hardly noteworthy. If you've written your own PDF to DOCX converter, then you have an interesting technical story (or ten) to tell -- do tell.
If so, it's hardly noteworthy. If you've written your own PDF to DOCX converter, then you have an interesting technical story (or ten) to tell -- do tell.
Successfully installed PyMuPDF-1.21.1 fire-0.5.0 fonttools-4.38.0 lxml-4.9.2 numpy-1.24.1 opencv-python-4.7.0.68 pdf2docx-0.5.6 python-docx-0.8.11 six-1.16.0 termcolor-2.2.0So, it's a wrapper around not panddoc but pdf2docx,
https://github.com/dothinking/pdf2docx
which parses PDF via PyMuPDF,
https://github.com/pymupdf/PyMuPDF
which is a wrapper around MuPDF (which does the heavy lifting parsing PDF),
and writes DOCX via python-docx,
However, from an everyday user point of view, it does make it rather simple to convert pdf to word document. An everyday user won't be up for doing that via cli commands. And every alternative user friendly solution requires uploading your documents to servers (which could spark privacy concerns)
If the customer base is less technically adept, wouldn't most of them not care and just upload it to a cloud service? I ask sincerely - recently I've realized I don't have as firm of a grip on the 'average consumer' as I thought.
The Windows app is an unsigned executable - not planning on running it myself.
What could possibly be missing at the moment is a written instruction that documents where to locate the code base on the user's machine post-installation
it's not will it sell it's how many will it sell
Getting PDFs into the pandoc intermediate representation would probably work on such a small subset of PDFs, pandoc does not even bother trying.