[reportlab-users] Post to reportlab-users waiting for moderator

[Robin Becker]

David Hughes wrote:

> Hi Robin,

> 

> Sorry to trouble you but I posted a query yesterday about problems with 

> _renderPM and OS X Universal builds. I included a zip file containing 

> examples and it got set aside for moderator intervention because of it's 

> size. I just checked the reference URL I was given but it's now coming 

> back with an invalid confirmation string. Does that mean the post has 

> been turned down?

> 


It's a bit large to send to our user group. I have looked at the message.

There is an endianness problem in PIL and with renderPM this is known for some 
time. Our setup.py has a check that's used in the libart library compilation; 
The PIL compilation has this in its setup.py

     if struct.unpack("h", "\0\1")[0] == 1:
         defs.append(("WORDS_BIGENDIAN", None))


I do know that it is possible to compile reportlab's extensions and PIL to work 
with at least some versions of OS X as we have done this ourselves, but not with 
the stock OS X python. Instead we build a python using the traditional make; 
make install dance and use that. I haven't tried this hardware switcheroo though.

You say the problem occurs when you run the intel version on the ppc box (and 
presumably vice-versa). That makes sense since the assumption of endianness is 
determined at compile time and is fixed thereafter. I'm not sure what should be 
done in this more dynamic case. Presumably the OS does some kind of translation 
on the code to map it to the alternate hardware, but it's clearly not doing it 
exactly. From what I can vaguely remember from this problem in the past your bg 
colours look similar to what used to happen (especially that sort of hatching).

I'm not a Mac expert, but it seems unreasonable to expect the dll to take care 
of this, I'm surprised that the intel dll even works. Can some Mac expert 
explain what's supposed to happen in this situation.
-- 
Robin Becker