Thanks to Everyone working on the Open Source Project

**BPFowler** · 05 August 2006, 11:31 AM

Originally Posted by Soquili

I don't have a Mac or know anyone that uses one to ask if they have success using it on their platform.

Neither of those XARs open on MacOS X because they contain PNGs and the file IO code has not yet been upgraded to byte swap PNGs (or that's the story, at least). I expect that the same will be seen on Linux PPC. This is Bug 929 "Failure reading PNG bitmap".

Are you willing to post a XAR with has neither a PNG nor a JPEG - the Mac will probably open it? I appreciate that the artwork shown here does need a background picture to work.

Ben

**Soquili** · 05 August 2006, 01:00 PM

Hi Ben,

The only bitmaps in the .xar files are those created within Xara Xtreme as bevels and fractal plasma fills. No bitmap images were imported to create the effects or backgrounds.

I edited the second gold file I posted above. I was surprised that Xara Xtreme LX did not recognize the existance of the bevels when I tried to remove them. I had to convert the shapes to Editable Shapes, and Ungroup to remove the bevels. I simply deleted the factal plasma filled rectangle used for the brushed metal effect. After removing the bevel from the text, I added an outline so it could be seen clearly. The shapes for the screws were removed completely as they were mostly beveled shapes and wasn't much remaining after removing the bevels.

Ben, if you receive the same error when trying to open the attached .xar file there is something more amiss than .png and .jpgs being used within Xara LX to simulate bevels and fractal plasma fills.

EDIT: Further examination of the original file shows that when first opened if you select a beveled object and then the bevel tool the program reports the bevel as None. If you make any change to the object, the bevel tool then recognises the bevel and reports it's type and allows it to be edited. I'll download the latest revision to see if this behavior is still happening.

**remi** · 05 August 2006, 04:22 PM

Bill, this is Bug 1234.

Regards,
Remi

**BPFowler** · 05 August 2006, 04:54 PM

Originally Posted by Soquili

Ben, if you receive the same error when trying to open the attached .xar file there is something more amiss than .png and .jpgs being used within Xara LX to simulate bevels and fractal plasma fills.

I can open that file. At the moment, there is a bright red cast to most of the files that I can open, as though looking through red cellophane (a few weeks ago it was blue), but I am pretty sure that it is rendering the same as your preview, and it is (to at least some extent editable).

Ben

**Soquili** · 05 August 2006, 07:12 PM

Thanks Remi. I got distracted doing yard work and didn't check to see if it was already on the bug list. Temperature today is only 104 F (40 C) degrees, so it was good weather for yard work compared to the evenings this past week.

Ben, it sounds like there is a considerable colour shift you see from the Linux files. Do you see the same shift when opening a .xar created in the windows version? Probably so, as I can open files from either version and see the same colours.

I'm curious as to whether or not you get an error when you apply a bevel to an object as you run Xtreme on your Mac?

**BPFowler** · 07 August 2006, 01:17 PM

It's not a colour shift, exactly (or at least I don't think so), but a very intense pure red background that seems to bleed into everything else.

Yes, bevels work fine for me. I can create a polygon, make an inner bevel and use the pointer dial ti illuminate it.

**GerryI** · 07 August 2006, 06:50 PM

I suspect this is caused by the "colour" initially set in the bitmap when rendering with transparency. This should be "fully transparent black" which on Windows/i386 is 0xFF000000. If this has not been correctly modified (or has been incorrectly modified) fo endian issues this could be being interpreted on the Mac as opaque red?

Gerry

**BPFowler** · 07 August 2006, 07:44 PM

Originally Posted by GerryI

I suspect this is caused by the "colour" initially set in the bitmap when rendering with transparency. This should be "fully transparent black" which on Windows/i386 is 0xFF000000. If this has not been correctly modified (or has been incorrectly modified) for endian issues this could be being interpreted on the Mac as opaque red?

I agree. If I ever feel that this is my pigeon, I will file a bug on it. I can't recall what the state is on Linux PPC - last time I tried to load a file, it did not work as well as the MacOS version.

I am fairly sure that nothing is swapped correctly, floating point values, Layer names and 32 bit colurs!

Ben.

**abligh** · 07 August 2006, 07:50 PM

Originally Posted by GerryI

I suspect this is caused by the "colour" initially set in the bitmap when rendering with transparency. This should be "fully transparent black" which on Windows/i386 is 0xFF000000. If this has not been correctly modified (or has been incorrectly modified) fo endian issues this could be being interpreted on the Mac as opaque red?

Gerry

I've fixed that particular one in r1676 but there is a lot of it about.

Alex