PyMuPDF is a fast, powerful and well-maintained PDF library for Python. Could it be added as an additional engine for img2pdf, or is the AGPL license a problem?
In case PyMuPDF gets added, I would suggest to remove pdfrw support, as the latter is not maintained anymore since a longer time (see also #108).
[PyMuPDF](https://github.com/pymupdf/PyMuPDF) is a fast, powerful and well-maintained PDF library for Python. Could it be added as an additional engine for img2pdf, or is the AGPL license a problem?
In case PyMuPDF gets added, I would suggest to remove pdfrw support, as the latter is not maintained anymore since a longer time (see also https://gitlab.mister-muffin.de/josch/img2pdf/issues/108).
I don't see how it can be possible to add mupdf as another engine option, because as far as I understand its API, one cannot control precisely the PDF objects. Instead PyMuPDF is a high-level library that is doing the fiddling with PDF objects for you.
I don't see how it can be possible to add mupdf as another engine option, because as far as I understand its API, one cannot control precisely the PDF objects. Instead PyMuPDF is a high-level library that is doing the fiddling with PDF objects for you.
I think PyMuPDF even has its own means to add images to PDFs, so img2pdf would not be necessary anyway.
I think PyMuPDF even has [its own means](https://pymupdf.readthedocs.io/en/latest/faq.html#how-to-add-images-to-a-pdf-page) to add images to PDFs, ~~so img2pdf would not be necessary anyway~~.
I think PyMuPDF even has its own means to add images to PDFs, so img2pdf would not be necessary anyway.
It is, because that API function is not able to insert some of the images that img2pdf can insert into a PDF.
> I think PyMuPDF even has [its own means](https://pymupdf.readthedocs.io/en/latest/faq.html#how-to-add-images-to-a-pdf-page) to add images to PDFs, so img2pdf would not be necessary anyway.
It is, because that API function is not able to insert some of the images that img2pdf can insert into a PDF.
Right, I expressed myself awkwardly. I didn't mean this method would be equivalent to img2pdf, but it would at least cover the basic functionality of adding images to PDFs.
It's just that if I were to develop an application with PyMuPDF, I would probably not use img2pdf and accept that some image types are not supported, rather than add an additional dependency and so on.
Right, I expressed myself awkwardly. I didn't mean this method would be equivalent to img2pdf, but it would at least cover the basic functionality of adding images to PDFs.
It's just that if I were to develop an application with PyMuPDF, I would probably not use img2pdf and accept that some image types are not supported, rather than add an additional dependency and so on.
PyMuPDF is a fast, powerful and well-maintained PDF library for Python. Could it be added as an additional engine for img2pdf, or is the AGPL license a problem?
In case PyMuPDF gets added, I would suggest to remove pdfrw support, as the latter is not maintained anymore since a longer time (see also #108).
I don't see how it can be possible to add mupdf as another engine option, because as far as I understand its API, one cannot control precisely the PDF objects. Instead PyMuPDF is a high-level library that is doing the fiddling with PDF objects for you.
Oh, okay, I didn't know that.
I think PyMuPDF even has its own means to add images to PDFs,
so img2pdf would not be necessary anyway.It is, because that API function is not able to insert some of the images that img2pdf can insert into a PDF.
Right, I expressed myself awkwardly. I didn't mean this method would be equivalent to img2pdf, but it would at least cover the basic functionality of adding images to PDFs.
It's just that if I were to develop an application with PyMuPDF, I would probably not use img2pdf and accept that some image types are not supported, rather than add an additional dependency and so on.