[reportlab-users] Problem with _renderPM across Mac hardware

[Robin Becker]

David Hughes wrote:

> Hi Robin,

> 

> Re the problem of building _renderPM on Intel and running it on PPC 

> hardware and vice-versa. I haven't asked about this anywhere else yet 

> but have done a bit more poking around.

> 

> It's to do with the way art_rgb_svp_alpha writes RGB values to its 

> buffer when painting fills. The first few values seem OK then the 

> sequence consistently goes wrong - when viewed in groups of 4 bytes, 

> bytes 2 and 3 are reversed in the cross-hardware case:

> 

>         Self                       Cross

>       1 2 3 4                   1 2 3 4

>       .  .  .  R                  .  .  . R

>       G B R G                G B R G

>       B R G B                B R G B

>       R G B R                R B G R

>       G B R G                G R B G

>       B R G B                B G R B

>       R G B R                R B G R

>       G B R G                G R B G      

> etc.  The sequence staying wrong until the next shape boundary.  I was 

> using a simple rectangle but in the general case I don't think it would 

> be possible to correct anything retrospectively. I haven't a clue how 

> the art_ routines work but there's a lot of bit shifting and twitching 

> going on and its possible the routine(s) may have to be hand-modified to 

> fix them. See 

> http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary.pdf  

> - eg. page 58.

> 

> I found a later version (2.3.19) of libart_lgpl but it was no different. 

> Development doesn't seem to be very active - the original developer has 

> moved on and http://bugzilla.gnome.org/enter_bug.cgi?product=libart is 

> all rather negative.

> 

> There is a  Mac-specific version of libart_lgpl from DarwinPorts 

> although I'm not too hopeful that it will be any different. But I 

> installed it, and it did give messages about applying patches. I have 

> now got various libart .a and .dylib files in /opt/local/lib but I don't 

> know how to modify setup.py in renderPM to use these instead of 

> compiling its own sources.  Is it worth you taking a look?

> 

> Regards,

.......

Easiest would be to see if the mac specific stuff (including patches) has 
anything relevant to this issue. I looked through art_rgb_svp.c, but there are 
no usages of the BIGENDIAN  there so I assume that there's either some kind of 
omission or the problem lies elsewhere.

The difficulty for me is that I expect the byte orders to go wrong when using 
software compile for littleending when used on bigendian and vice-versa. Looking 
in your reference they make specific reference to byte swapping ie the binary 
has to use special techniques to read and write external data. That's precisely 
what these old style programs don't do ie they assume they only run on one platform.

If we're to adopt the approach used by Apple we need to make the ordering 
assumptions dynamic ie instead of having a macro define at run time what happens 
we need to do a test at start time and set up appropriate globals to take care 
of the switch dynamically.

If you're willing I can try and make a test version of the code that would do 
that for you. It still won't alter the assumptions made in PIL though.
-- 
Robin Becker