really really disappointed in Pro 5 demo

[jonnycross]

I just spent a week of my spare time doing a graphic using Xara Xtreme 5 demo
and I have lost it due to the out of memory bug.
I tried the Xpandxar but to no avail. I never came across this in version 4 ( did it exist then or is it something new to 5)
I am attaching the file here hoping that someone who knows what their doing can assist.peg.xar
TIA Jon

[Soquili]

Jon it looks like that file is Xtremely corrupt. Not even the embedded gif is intact.

[gwpriester]

Ack! Hate that.

If you had downloaded and installed XaReg Bill and Steve's excellent Free utility, you could have set Xtreme to create a backup (BAK) copy of your file every time you saved it.

My theory, proved dozens of times by me personally, is the longer you go without saving your work, the greater your chances of losing your work with a program crash.

[jonnycross]

Thanks guys but the program was saved on a regulaur basis,I do so every time I complete a layer (habit).
the gif is still there horse002.bmp
I will just have to start again
Downed Xareg installing it now
My thanks to Bill and Steve for the Utiity
regards Jon

[GerryI]

This is a bit strange. I've never seen a file corrupted in that particular way before. The only thing wrong with the file is that the record length of the preview bitmap is not correctly set. Once I corrected this by manually locating the end of the GIF and calculating the length, the file loads correctly.

Hope this helps and you haven't spent too long redrawing it...

Gerry

[steve.ledger]

Five Star support from Xara!!

Good stuff Gerry

[gwpriester]

Try getting that kind of service from Adobe.

[Soquili]

Gerry rescues another lost file.

Gerry would you share some tips on how to identify the end of the embedded bitmap?

Thanks

[GerryI]

Well, in the case of the preview bitmap, the next record should always be the TAG_DOCUMENT record. This has a Tag ID of 40 (0x00000028) and a size of 0 and is always followed by a TAG_DOWN record (id is 1 or 0x00000001 and a size of 0). This makes it easy to search if your binary editor allows easy searching though you have to handle the byte ordering yourself (e.g. the bytes for the document and down records are 28 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00).

Alternatively, there is almost always an easily visible bit of unicode text just after the end of the bitmap containing record descriptions for some of the records that have been added over the years. You can simply scroll through until you see something that looks like "Spread properties" with extra NULL bytes between all the characters. Then go back about 32 bytes from the start of that and you should be at the document record mentioned above.

For other images in the document, the compression is turned off before the image record and turned back on afterwards so you can usually use the tag number of a bitmap definition record (67 or 0x00000043 for JPEG and 68 or 0x00000044 for PNG) to find the start and then use the start compression record to find the end (tag id 30 or 0x0000001e, always 4 bytes and the data always contains 0x00000063). This makes "1e 00 00 00 04 00 00 00 63 00 00 00".

Gerry

[Soquili]

Thank you very much Gerry.