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

[David Hughes]

Robin Becker wrote:

> 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.

For information, my original post - without the examples that were 
attached - read:

> My problem was originally reported in an application, bundled using 

> py2app on an Intel machine running OS X 10.4 (Tiger), by a customer 

> running it on a PPC box running 10.3.9 (Panther), but it can be 

> demonstrated with any version of the OS and without using py2app - in 

> this case Leopard installed on a removable disk that's swappable 

> between Intel and PPC laptops and using renderPM 1.04 downloaded from 

> your daily builds (30 Nov).

>

> The background colour of graphs written to PNG are fine when run on 

> the same architecture that built *_renderPM.so* but when running an 

> Intel-built version on a PPC box, or vice-versa, the background 

> appears like closely-hatched grey lines (see examples in attached zip 

> file). The two *.so* files, also attached, are very similar but 

> contain a scattering of mainly one- and two-byte differences. The 

> build-logs contain some warnings, but the same in both. 

> Test_renderPM.py  doesn't throw any errors.

>

> I'm wondering if there is an implicit assumption somewhere about the 

> Endian-ness of the underlying processor but, in my ignorance, I'm 

> stuck and would be grateful for any assistance.

>

Also for information, the builds of Python and PIL that I'm using are 
those downloaded from  www.pythonmac.org/packages/py25-fat/index.html
Does anyone have any objections if I cross-post this to pythonmac-sig?

Regards,

David Hughes
Forestfield Software

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20071204/651ef992/attachment.html>