[reportlab-users] renderPM

Robin Becker reportlab-users@reportlab.com
Fri, 26 Jul 2002 11:57:54 +0100


In article <216AA456-A07D-11D6-A12D-00039345C610@darwin.in-berlin.de>,
Dinu Gherman <gherman@darwin.in-berlin.de> writes
>Jerome Alet:
>
>> I've downloaded pyRXP to give it a look and see how it works.
>> May I suggest that the tarball be made from one level above,
>> as it is usually the case for most existing software ?
>> All pyRXP files are now in my home directory :-(
>
>Jerome, I've come along the very same problem/suggestion just
>yerstday! ;-) The official answer is the usual one and tied to
>time and resources. Combine this with vacations, funerals and
>deadlines and you know what to think. I'm very sorry! August
>might be slightly better again.
>
>Dinu
Dinu, I did some work on the renderPM image shapes last week, but only
checked them in yesterday. There were also some problems with the latest
version of libart that was being used. Apparently no-one else has
seen(or reported) these problems, but I still need someone to thrash on
this code.

The basic image stuff is present already in renderPS, but it needs to be
interfaced correctly to the image shape. By the way it's a real problem
using the word Image as everyone seems to use that. I suppose it's too
late to change now.

I assumed the following

x, y are the origin of the image (bottom left corner)

width and height may be None or some number with None 
        corresponding to the image value. 

path may be an image filename or a PIL image. We should probably allow
for a python file, but I didn't do that yet. My tests seem to work if I
assume that the scan lines for gifs etc are the wrong way round and the
images seem to behave OK under rotation/skewing.

There remains the problem of caching images etc, currently I'm not doing
anything about that.

Also I need someone to scan _renderPM.c at the section marked 

ifndef CLEE_CODE

I replaced some of his stuff and things seem to work fine with the new
libart intersector. If I use it I get problems related to bleeding fills
etc. I know he intended to fix problems related to winding number vs
transform. What I need are some disambiguating cases that tell us
whether the code really works in the presence of transforms that have
determinant < 0 (eg a y-axis flip). Things seem OK to me, but I'm
probably unimaginative.
-- 
Robin Becker