[reportlab-users] Patch: PIL images with ReportLab

[Sam Hunter]

Yeah, I think it should be okay.. but I"m not a Java kid by any means :)

What I'd really like to do is fix the canvas.drawImage() function so 
that it would just accept PIL images.

  It looks like parts of canvas were originally designed to handle PILs, 
but that functionality was broken when the drawImage() function was 
written because it does MD5 sums, and needs the rawdata to do the MD5 
sum with. 

  I fixed that problem (canvas.py lines 564-575), but that has exposed 
another issue.

  The canvas,drawImage() function calls 
PDFImageXObject.loadImageFromSRC() function which seems to be built for 
loading PIL Image object, but it is a little messed up because it tries 
to access their format information with
"im._image.format"
  Normal PIL Image objects don't have a "_image" member, and that 
".format" is only valid if you haven't changed the PIL image in any way 
(a resize sets it to Null). 

  I am currently working on a way to have the PIL image convert itself 
to something so that the line "self.loadImageFromJPEG(fp)" (pdfdoc.py 
line 1827ish) doesn't even need to be run.  As far as I can tell, all of 
the self.* members that loadImageFromJPEG() sets are available from 
various PIL information functions, and I would imagine that the 
self.streamContent could probably be generated with some kind of PIL 
function as well.  If not, the data in imageFile could.

Does anyone know if these functions are used for things other than PIL 
image types?  Has this path through the code been broken at the 
beginning for so long that it is just way out of date, or was it broken 
to make something else work?

thanks :)

Sam

Andy Robinson wrote:

>> I've been fighting with using PIL images and ReportLab on and off for a 
>>few days now, and finally took at look at the utils.py code to see how 
>>ImageReader works.  Basically it looks like it accepts a file name or 
>>file like object and then loads it as a PIL image if the platform is NOT 
>>java, and uses some java image type if it is.
>> It seemed somewhat circuitous to take a PIL image, put it in a StringIO 
>>wrapper, create an ImageReader object with it, to have the 
>>ImageReader.__init__  convert it back to a PIL image.   Why not just 
>>make the __init__ accept PIL images in the first place?
>>    
>>
>
>Thanks Sam.  You're right, this does sound silly.
>
>I think this was all done by a Java person we had here a 
>while ago who (quite impressively) go 100% byte-identical
>output from the test suite, and we haven't thought hard about 
>it since.   He didn't know much about PIL.
>
>We need to check it does not break under Jython 2.1,
>but obviously it will not be passed PIL images in
>that case.  So I have no problem in principle with
>making PIL Image objects legal and simplifying it.
>
>Robin, any opinions?  (answer expected tomorrow UK time)
>  
>
>- Andy Robinson
>  
>
>> So, I made a few small modifications.  They work perfectly in my small 
>>test script.  If they look good, could it go into the source?
>> Also, it looks like the canvas.drawImage() could very easily be 
>>modified to take PILs as well.
>>
>>Thanks,
>>
>>Sam Hunter
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://two.pairlist.net/pipermail/reportlab-users/attachments/20050427/4a1b3dc7/attachment.html