Open epalm opened 7 years ago
Thanks to you too. There are two assumtions: 1) load_resource() are considered to be overloaded for other data sources 2) reading files directly from memory are handfull too, but i can imagine simple and clean method for specifying this, other than 'base64://' pseudo-url
Right. I would think that the load_resource
function would remain untouched (there's nothing to load, you already have the bytes), and the _parsexxx
functions could just proceed without calling load_resource
at all.
same here, many thanks for this great library.
I'm having exactly the same issue. It would be great if you could provide a method for specifying the image in memory.
At the moment I would also be fine with a load_resource
workaround. I have a dependency to fpdf for my project but it seems the package on PyPI does not contain the latest version. In this version there is no load_resource
method. Could you update the version on PyPI?
Under the assumption that the Pillow people have figured out the technical kinks that previously prevented people from using their library:
check out this implementation - i tried my best but it came out slower than the original: usage, and partial implementation details:
Looking forward to your guys feedback, if this is something i should finish for jpg file and merge back into at least my own master.
for reference, you can run that test either by changing directory into that folder and running the file, (this will use the timing code i have in the file), or by checking out the branch and simply running tox
command. This version of the library has explicit Pillow dependency.
speed difference isn't quite consistent though:
$ python png_image_test.py -vv
test_insert_png_files (__main__.InsertPNGSuiteFiles) ... ok
__main__.InsertPNGSuiteFiles: 0.489
test_insert_png_memory (__main__.InsertPNGSuiteMemory) ... ok
__main__.InsertPNGSuiteMemory: 0.544
----------------------------------------------------------------------
Ran 2 tests in 1.033s
OK
The numbers seem to have righted themselves after testing out on a clean virtual machine install after some big fixes in the test.
$ python png_image_test.py -vv
test_insert_png_files (__main__.InsertPNGSuiteFiles) ... ok
__main__.InsertPNGSuiteFiles: 0.836
test_insert_png_memory (__main__.InsertPNGSuiteMemory) ... ok
__main__.InsertPNGSuiteMemory: 0.738
----------------------------------------------------------------------
Ran 2 tests in 1.575s
OK
Just found this through Google. Is adding images from memory supported now? going through files is not really an option for me. Thanks.
Just found this through Google. Is adding images from memory supported now? going through files is not really an option for me. Thanks.
Same here Please add a funcion. Thanks
i have been releasing stuff on pyfpdf2, my fork of this project, you can pass BytesIO instance as name of the image and it uses pillow
On Tue, Sep 15, 2020 at 11:48 AM BlockChain Caffè notifications@github.com wrote:
Same here Please add a funcion. Thanks
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reingart/pyfpdf/issues/85#issuecomment-692805203, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACECGJDVC6YCXW7RKCOQ5QLSF6EERANCNFSM4DHUWLZQ .
PyFPDF is not maintained anymore, you may want to check PyFPDF/fpdf2 as its successor, with a 99%-compatible API
It does support inserting images from memory, as bytes
First of all I need to say, thanks so much for providing and maintaining a Python pdf generation library with a sane API and good documentation.
I'm first using Pillow to generate an image, and then inserting the image into a pdf using FPDF.
Currently I have to
image('path/to/file', ...)
which calls_parsepng(filename)
which callsload_resource(filename)
which finally callsopen(filename, "rb")
Since I have the image already loaded in memory, if I could pass those bytes to the
image
function then I could avoid touching the disk altogether.