Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP; CAUSE IDENTIFIED]
On 12/08/11 14:38, planas wrote: On Fri, 2011-08-12 at 13:52 +1000, Simon Cropper wrote: Hi Everyone, I have been doing some follow-up investigations that I thought you might like to be made aware. First, why? Well after testing the file that I recreated by copying the text, formula and styles I could not cause the error to occur again. This is what I reported yesterday. I then proceeded with importing the few images and 'artwork' objects from the old file to the new. After several saves and sheet manipulations I noticed the file became unstable again. The outcome of my investigation was that one of the image files used on one of the sheets had become corrupted* and adding this file in caused the file to become unstable - eventually exhibiting the problem I mentioned about not being able to save after a sheet was deleted. These 'corrupted' files are relatively benign with the error only becoming apparent *once* you attempt to delete the sheet. So somehow the error caused problems with the broader 'workbook' structure not the sheet structure. Although I compared files between different versions of the file the XML were too varied (usually style names and definitions; content was identical). * note I say corrupted but it rendered OK and only resulted in the observed behaviour one a sheet is deleted. I 'deem' it corrupted as once replaced with a clean version render and saved as a new file by GIMP, the problem disappeared. The error was with the particular corrupt objects. On recreating new images and inserting them into a file I have not been able to trigger any problems. If I cut-and-paste from the original 'corrupt' file the file becomes unstable after a few saves and sheet manipulations. So the steps for salvage is... 1. recreate a new file with the exact number of sheets as the original. Ensure each sheet names are the same. 2. Cut and Paste each sheet. Make sure you 'Paste special' limiting the content being placed in the new file to text, numbers, date time, formulas and formats. 3. If you have images in the file. Recreate / Save using another package. As mentioned I used GIMP. 4. Insert new copies of the images into file. *Don't* cut-and-paste objects from the old file. 5. If you have any lines, text boxes and artwork; recreate them from new. During this process... - Save as a new version (+tabs, +data, +images, +other objects) following each step. - Test each version thoroughly before proceeding. - Only add one object at a time, so if something goes wrong you can isolate the problem component. - To check it is not a bug try and recreate with a fresh file. A couple of quick notes that may be valuable to others... - ODS files are archives. Use an archive facility to extract the data inside. Inspect the contents in the folders to see what is different. - On every 'Save as' the file size changes. This is not due to changes in the file contents, but rather in changes in how the components of the file is compressed/archived. If you open a file, add objects then save, the file size with be so big. Open that file and Save as a new name and the file will be a different size. If you extract the files the contents of all the files and directories are identical. It is just the internal archive facility in LO will decide the best compaction routine based on what it encounters. - The content.xml file can be quite large and has no internal end-of-line characters. This make it difficult to open and be parse by various text editors, xml viewers and comparison facilities. To insert a EOL character after the end of each tag (i.e.), I used the following command in the terminal (requires Linux). cat content.xml | sed -e 's//\n/g' content_with_linebreaks.xml cat just spews the content of the text file to the standard output. I then pipe it to sed, where I used regular expressions to find '' and replace every instance of it with '\n'. I then compared the contents with Diffuse. Snip +1 I wonder how the images got corrupted, interesting. Good question and something I was not happy just leaving alone. Once I satisfied myself that this was most likely not a bug but file corruption the questions that came to mind were... (1) How this file became corrupted? and (2) How extensive is the damage (physical damage, system wide, file specific)? As mentioned I currently use Linux so needed to find a method to check the file system for errors and see if any blocks or clusters were damaged. I am assuming here that I could of had a power spike or jolt to my machine that could of caused the platter on my hard disk becoming damaged. I did this by running 'fsck.ext4' from a LiveCD on all my hard disks. It took all Saturday to do this. Thankfully no errors were detected. Anyone interested in how I did this can check out my more specific response on the Ubuntu Forums... http://ubuntuforums.org/showthread.php?p=11152491#post11152491 This left me with an event
Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP]
*** Jorge, as I respond to your email I find out a range of things of note, as I try and support or refute my ideas. It is enlightening to read the entire post but you can just as easily jump to HERE *** Sorry Jorge, I suppose it is confusing. The problem is the corruption due to the insertion of the image is not immediately obvious. Then as the file becomes more progressively more corrupt. The sequence was like this 1. Cut-and-paste data 2. Reinsert images and objects 3. Other stuff... 4. Issue with comments noted What surprised me was after recreating a clean file for use I then ended up with an error popping up. No comments were found anywhere. So I stripped the file back to the individual components -- data, format, images, etc. Adding each one separately then testing extensively. On adding the images I noted some funny stuff happening to the file size. as I saved, re-saved, deleted sheets, re-saved, etc... I noticed that the file showed more problems rendering images (images disappeared as well as references to files disappeared). Soon afterwards the file had problems saving after deletion of the sheet. So I presume that the images caused the corruption of the structure, the problem progressively got worse, then the comments field tipped the scale and caused the error in saving after the deletion of the sheet. anyway that seems as plausible as any explanation I have seen already. As stated I am unable to reproduce these errors on new files. despite trying repeatedly for hours. As stated previously I was able to shake the problem by cutting-and-pasting the data into the spreadsheet. This included everything images and all. I could not trigger the error despite hours of testing. Consequently I posted the 'solution' to this thread. After several hours of adding and deleting data, the problem reappeared. As stated I then recreated the file including data-formula-format, minus other objects then progressively built up the file until it mimicked the original. Each step I tested, retested and checked yet again. In the end I noted things got 'wonky' after insertion of the images-artwork. this did not particularly make sense to me but I persisted in splitting the objects being inserted in the document until I could identify the culprit. This eventually identified a single image (originally a GIF that was converted to a PNG). Add this image to the sheet and progressively problems appear. If I recreate a PNG file using GIMP and insert this I can't get the problems to appear. This is using the same file, data and files - side by side. Very confusing. There is only two conclusions (a) that the file is corrupt, something corrupted it and at present the first thing I notice a problem occurring after it is inserted is this image. (b) that LO accesses and manipulated the file incorrectly. In other words their is a bug in the code. As I am not inclined to post a file with all my financial details on the Internet, and I have no other versions of LO around to test the second theory I am in a quantry. HERE Well... As it turns out I have an old version of OpenOffice 3.1.0 OOO310m11 (Build: 9399) lying around on an old Windows Vista laptop I was unaware about. Exact same file (except for one computer is accessing the local drive and the other a SAMBA network drive)... - LO baulks with the error blah blah unable to write - OO does not! Wh? Alright I am on Ununtu. I opened a copy of the file via nautilus from a local drive mounted using fstab - the error occurs. If I use nautilus to locate and access the same samba share the windows machine used - the error occurs. Somehow I am relieved. OK, I test using another machine ubuntu-ubuntu using LO 3.3.2, both via a NFS mount and Samba share. Both sheet deletions and saved worked on the exact same file that my machine baulks with - that is the error did not occur. I am bloody confused! The problem is computer specific and file specific. As part of the entire exercise I completely uninstalled every LO related package and reinstalled them with all the dependencies. I have check and rechecked the file permissions, ownerships and groups. Nothing untoward. Anyone got any ideas? if the disk was damaged then then all computer would complain. This leaves be with some conflict or background process that is interfering with the operation I am trying to do... you know the operation I can reproduce on any other file, except when I cut and paste data from the original file. Sound a lot like a corrupt disk, but how does the NFS and Samba Shares NOT trigger this error. On 12/08/11 14:28, jorge wrote: Hi I'm some confused. Was the comment or the image the problem ? or Both ? Regards, Jorge Rodríguez _ El vie, 12-08-2011 a las 13:52 +1000, Simon Cropper escribió: Hi Everyone, I have been doing some follow-up investigations that I thought you might like to be made aware.
Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP]
On 12/08/11 14:38, planas wrote: On Fri, 2011-08-12 at 13:52 +1000, Simon Cropper wrote: Hi Everyone, I have been doing some follow-up investigations that I thought you might like to be made aware. First, why? Well after testing the file that I recreated by copying the text, formula and styles I could not cause the error to occur again. This is what I reported yesterday. I then proceeded with importing the few images and 'artwork' objects from the old file to the new. After several saves and sheet manipulations I noticed the file became unstable again. The outcome of my investigation was that one of the image files used on one of the sheets had become corrupted* and adding this file in caused the file to become unstable - eventually exhibiting the problem I mentioned about not being able to save after a sheet was deleted. These 'corrupted' files are relatively benign with the error only becoming apparent *once* you attempt to delete the sheet. So somehow the error caused problems with the broader 'workbook' structure not the sheet structure. Although I compared files between different versions of the file the XML were too varied (usually style names and definitions; content was identical). * note I say corrupted but it rendered OK and only resulted in the observed behaviour one a sheet is deleted. I 'deem' it corrupted as once replaced with a clean version render and saved as a new file by GIMP, the problem disappeared. The error was with the particular corrupt objects. On recreating new images and inserting them into a file I have not been able to trigger any problems. If I cut-and-paste from the original 'corrupt' file the file becomes unstable after a few saves and sheet manipulations. So the steps for salvage is... 1. recreate a new file with the exact number of sheets as the original. Ensure each sheet names are the same. 2. Cut and Paste each sheet. Make sure you 'Paste special' limiting the content being placed in the new file to text, numbers, date time, formulas and formats. 3. If you have images in the file. Recreate / Save using another package. As mentioned I used GIMP. 4. Insert new copies of the images into file. *Don't* cut-and-paste objects from the old file. 5. If you have any lines, text boxes and artwork; recreate them from new. During this process... - Save as a new version (+tabs, +data, +images, +other objects) following each step. - Test each version thoroughly before proceeding. - Only add one object at a time, so if something goes wrong you can isolate the problem component. - To check it is not a bug try and recreate with a fresh file. A couple of quick notes that may be valuable to others... - ODS files are archives. Use an archive facility to extract the data inside. Inspect the contents in the folders to see what is different. - On every 'Save as' the file size changes. This is not due to changes in the file contents, but rather in changes in how the components of the file is compressed/archived. If you open a file, add objects then save, the file size with be so big. Open that file and Save as a new name and the file will be a different size. If you extract the files the contents of all the files and directories are identical. It is just the internal archive facility in LO will decide the best compaction routine based on what it encounters. - The content.xml file can be quite large and has no internal end-of-line characters. This make it difficult to open and be parse by various text editors, xml viewers and comparison facilities. To insert a EOL character after the end of each tag (i.e.), I used the following command in the terminal (requires Linux). cat content.xml | sed -e 's//\n/g' content_with_linebreaks.xml cat just spews the content of the text file to the standard output. I then pipe it to sed, where I used regular expressions to find '' and replace every instance of it with '\n'. I then compared the contents with Diffuse. Snip +1 I wonder how the images got corrupted, interesting. planas, See my reply to Jorge. In particular the discovery that suggests that the file may be physically damaged, or at lease the sector that it resides. I am going to check for damage now. -- Cheers Simon Simon Cropper Principal Consultant Botanicus Australia Pty Ltd PO Box 160, Sunshine, VIC W: www.botanicusaustralia.com.au -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP]
Hi I don't know what will be happening. But I think that if in other computer or program LO 3.3.2 you don't have problem to use the file, ...the file ins't corrupted and newer LO neither. I think that Vista or the OpenOffice 3.1.0 would lose something as program by whatever way and / or the computer where you have it installed has something fisical bad. I suggest you a probe (If you have some free time): Why not install again OpenOffice 3.1.0 in other computer and try to use the file? (With and without new Vista installation) Regards, Jorge Rodríguez ___ El vie, 12-08-2011 a las 16:04 +1000, Simon Cropper escribió: *** Jorge, as I respond to your email I find out a range of things of note, as I try and support or refute my ideas. It is enlightening to read the entire post but you can just as easily jump to HERE *** Sorry Jorge, I suppose it is confusing. The problem is the corruption due to the insertion of the image is not immediately obvious. Then as the file becomes more progressively more corrupt. The sequence was like this 1. Cut-and-paste data 2. Reinsert images and objects 3. Other stuff... 4. Issue with comments noted What surprised me was after recreating a clean file for use I then ended up with an error popping up. No comments were found anywhere. So I stripped the file back to the individual components -- data, format, images, etc. Adding each one separately then testing extensively. On adding the images I noted some funny stuff happening to the file size. as I saved, re-saved, deleted sheets, re-saved, etc... I noticed that the file showed more problems rendering images (images disappeared as well as references to files disappeared). Soon afterwards the file had problems saving after deletion of the sheet. So I presume that the images caused the corruption of the structure, the problem progressively got worse, then the comments field tipped the scale and caused the error in saving after the deletion of the sheet. anyway that seems as plausible as any explanation I have seen already. As stated I am unable to reproduce these errors on new files. despite trying repeatedly for hours. As stated previously I was able to shake the problem by cutting-and-pasting the data into the spreadsheet. This included everything images and all. I could not trigger the error despite hours of testing. Consequently I posted the 'solution' to this thread. After several hours of adding and deleting data, the problem reappeared. As stated I then recreated the file including data-formula-format, minus other objects then progressively built up the file until it mimicked the original. Each step I tested, retested and checked yet again. In the end I noted things got 'wonky' after insertion of the images-artwork. this did not particularly make sense to me but I persisted in splitting the objects being inserted in the document until I could identify the culprit. This eventually identified a single image (originally a GIF that was converted to a PNG). Add this image to the sheet and progressively problems appear. If I recreate a PNG file using GIMP and insert this I can't get the problems to appear. This is using the same file, data and files - side by side. Very confusing. There is only two conclusions (a) that the file is corrupt, something corrupted it and at present the first thing I notice a problem occurring after it is inserted is this image. (b) that LO accesses and manipulated the file incorrectly. In other words their is a bug in the code. As I am not inclined to post a file with all my financial details on the Internet, and I have no other versions of LO around to test the second theory I am in a quantry. HERE Well... As it turns out I have an old version of OpenOffice 3.1.0 OOO310m11 (Build: 9399) lying around on an old Windows Vista laptop I was unaware about. Exact same file (except for one computer is accessing the local drive and the other a SAMBA network drive)... - LO baulks with the error blah blah unable to write - OO does not! Wh? Alright I am on Ununtu. I opened a copy of the file via nautilus from a local drive mounted using fstab - the error occurs. If I use nautilus to locate and access the same samba share the windows machine used - the error occurs. Somehow I am relieved. OK, I test using another machine ubuntu-ubuntu using LO 3.3.2, both via a NFS mount and Samba share. Both sheet deletions and saved worked on the exact same file that my machine baulks with - that is the error did not occur. I am bloody confused! The problem is computer specific and file specific. As part of the entire exercise I completely uninstalled every LO related package and reinstalled them with all the dependencies. I have check and rechecked the file permissions, ownerships and groups. Nothing
Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP]
Hi Everyone, I have been doing some follow-up investigations that I thought you might like to be made aware. First, why? Well after testing the file that I recreated by copying the text, formula and styles I could not cause the error to occur again. This is what I reported yesterday. I then proceeded with importing the few images and 'artwork' objects from the old file to the new. After several saves and sheet manipulations I noticed the file became unstable again. The outcome of my investigation was that one of the image files used on one of the sheets had become corrupted* and adding this file in caused the file to become unstable - eventually exhibiting the problem I mentioned about not being able to save after a sheet was deleted. These 'corrupted' files are relatively benign with the error only becoming apparent *once* you attempt to delete the sheet. So somehow the error caused problems with the broader 'workbook' structure not the sheet structure. Although I compared files between different versions of the file the XML were too varied (usually style names and definitions; content was identical). * note I say corrupted but it rendered OK and only resulted in the observed behaviour one a sheet is deleted. I 'deem' it corrupted as once replaced with a clean version render and saved as a new file by GIMP, the problem disappeared. The error was with the particular corrupt objects. On recreating new images and inserting them into a file I have not been able to trigger any problems. If I cut-and-paste from the original 'corrupt' file the file becomes unstable after a few saves and sheet manipulations. So the steps for salvage is... 1. recreate a new file with the exact number of sheets as the original. Ensure each sheet names are the same. 2. Cut and Paste each sheet. Make sure you 'Paste special' limiting the content being placed in the new file to text, numbers, date time, formulas and formats. 3. If you have images in the file. Recreate / Save using another package. As mentioned I used GIMP. 4. Insert new copies of the images into file. *Don't* cut-and-paste objects from the old file. 5. If you have any lines, text boxes and artwork; recreate them from new. During this process... - Save as a new version (+tabs, +data, +images, +other objects) following each step. - Test each version thoroughly before proceeding. - Only add one object at a time, so if something goes wrong you can isolate the problem component. - To check it is not a bug try and recreate with a fresh file. A couple of quick notes that may be valuable to others... - ODS files are archives. Use an archive facility to extract the data inside. Inspect the contents in the folders to see what is different. - On every 'Save as' the file size changes. This is not due to changes in the file contents, but rather in changes in how the components of the file is compressed/archived. If you open a file, add objects then save, the file size with be so big. Open that file and Save as a new name and the file will be a different size. If you extract the files the contents of all the files and directories are identical. It is just the internal archive facility in LO will decide the best compaction routine based on what it encounters. - The content.xml file can be quite large and has no internal end-of-line characters. This make it difficult to open and be parse by various text editors, xml viewers and comparison facilities. To insert a EOL character after the end of each tag (i.e. ), I used the following command in the terminal (requires Linux). cat content.xml | sed -e 's//\n/g' content_with_linebreaks.xml cat just spews the content of the text file to the standard output. I then pipe it to sed, where I used regular expressions to find '' and replace every instance of it with '\n'. I then compared the contents with Diffuse. On 11/08/11 14:44, jorge wrote: Congratulations,... it was an interesting investigation. Regards, Jorge Rodríguez __ El jue, 11-08-2011 a las 11:50 +1000, Simon Cropper escribió: On 10/08/11 16:41, Simon Cropper wrote: *The upshot* Unless someone recognised these symptoms and can put forward some ideas, I am treating this as a corrupt file. I have drawn this conclusion because (a) I can only reproduce the error on the effected file, (b) the comment insert/delete trick is suggestive but not consistent (or at least from what I can tell) - random sheets cause the file save error if comments are inserted; inserting comments into new sheets also trigger the error. I just hope that recreating this file does not corrupt the new file as I will need to copy blocks of text, numbers and formulas. *My attempts at recreating a clean file* ATTEMPT 1 Created a new file with one less tab. All tabs were named the same as the original. I then cut-and-paste all the data from the original to this newly created file. This took about 10
Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP]
Hi I'm some confused. Was the comment or the image the problem ? or Both ? Regards, Jorge Rodríguez _ El vie, 12-08-2011 a las 13:52 +1000, Simon Cropper escribió: Hi Everyone, I have been doing some follow-up investigations that I thought you might like to be made aware. First, why? Well after testing the file that I recreated by copying the text, formula and styles I could not cause the error to occur again. This is what I reported yesterday. I then proceeded with importing the few images and 'artwork' objects from the old file to the new. After several saves and sheet manipulations I noticed the file became unstable again. The outcome of my investigation was that one of the image files used on one of the sheets had become corrupted* and adding this file in caused the file to become unstable - eventually exhibiting the problem I mentioned about not being able to save after a sheet was deleted. These 'corrupted' files are relatively benign with the error only becoming apparent *once* you attempt to delete the sheet. So somehow the error caused problems with the broader 'workbook' structure not the sheet structure. Although I compared files between different versions of the file the XML were too varied (usually style names and definitions; content was identical). * note I say corrupted but it rendered OK and only resulted in the observed behaviour one a sheet is deleted. I 'deem' it corrupted as once replaced with a clean version render and saved as a new file by GIMP, the problem disappeared. The error was with the particular corrupt objects. On recreating new images and inserting them into a file I have not been able to trigger any problems. If I cut-and-paste from the original 'corrupt' file the file becomes unstable after a few saves and sheet manipulations. So the steps for salvage is... 1. recreate a new file with the exact number of sheets as the original. Ensure each sheet names are the same. 2. Cut and Paste each sheet. Make sure you 'Paste special' limiting the content being placed in the new file to text, numbers, date time, formulas and formats. 3. If you have images in the file. Recreate / Save using another package. As mentioned I used GIMP. 4. Insert new copies of the images into file. *Don't* cut-and-paste objects from the old file. 5. If you have any lines, text boxes and artwork; recreate them from new. During this process... - Save as a new version (+tabs, +data, +images, +other objects) following each step. - Test each version thoroughly before proceeding. - Only add one object at a time, so if something goes wrong you can isolate the problem component. - To check it is not a bug try and recreate with a fresh file. A couple of quick notes that may be valuable to others... - ODS files are archives. Use an archive facility to extract the data inside. Inspect the contents in the folders to see what is different. - On every 'Save as' the file size changes. This is not due to changes in the file contents, but rather in changes in how the components of the file is compressed/archived. If you open a file, add objects then save, the file size with be so big. Open that file and Save as a new name and the file will be a different size. If you extract the files the contents of all the files and directories are identical. It is just the internal archive facility in LO will decide the best compaction routine based on what it encounters. - The content.xml file can be quite large and has no internal end-of-line characters. This make it difficult to open and be parse by various text editors, xml viewers and comparison facilities. To insert a EOL character after the end of each tag (i.e. ), I used the following command in the terminal (requires Linux). cat content.xml | sed -e 's//\n/g' content_with_linebreaks.xml cat just spews the content of the text file to the standard output. I then pipe it to sed, where I used regular expressions to find '' and replace every instance of it with '\n'. I then compared the contents with Diffuse. On 11/08/11 14:44, jorge wrote: Congratulations,... it was an interesting investigation. Regards, Jorge Rodríguez __ El jue, 11-08-2011 a las 11:50 +1000, Simon Cropper escribió: On 10/08/11 16:41, Simon Cropper wrote: *The upshot* Unless someone recognised these symptoms and can put forward some ideas, I am treating this as a corrupt file. I have drawn this conclusion because (a) I can only reproduce the error on the effected file, (b) the comment insert/delete trick is suggestive but not consistent (or at least from what I can tell) - random sheets cause the file save error if comments are inserted; inserting comments into new sheets also trigger the error. I just hope that recreating this file does not corrupt the new file as I will need
Re: [libreoffice-users] Calc will not save file after sheet deleted [FOLLOW-UP]
On Fri, 2011-08-12 at 13:52 +1000, Simon Cropper wrote: Hi Everyone, I have been doing some follow-up investigations that I thought you might like to be made aware. First, why? Well after testing the file that I recreated by copying the text, formula and styles I could not cause the error to occur again. This is what I reported yesterday. I then proceeded with importing the few images and 'artwork' objects from the old file to the new. After several saves and sheet manipulations I noticed the file became unstable again. The outcome of my investigation was that one of the image files used on one of the sheets had become corrupted* and adding this file in caused the file to become unstable - eventually exhibiting the problem I mentioned about not being able to save after a sheet was deleted. These 'corrupted' files are relatively benign with the error only becoming apparent *once* you attempt to delete the sheet. So somehow the error caused problems with the broader 'workbook' structure not the sheet structure. Although I compared files between different versions of the file the XML were too varied (usually style names and definitions; content was identical). * note I say corrupted but it rendered OK and only resulted in the observed behaviour one a sheet is deleted. I 'deem' it corrupted as once replaced with a clean version render and saved as a new file by GIMP, the problem disappeared. The error was with the particular corrupt objects. On recreating new images and inserting them into a file I have not been able to trigger any problems. If I cut-and-paste from the original 'corrupt' file the file becomes unstable after a few saves and sheet manipulations. So the steps for salvage is... 1. recreate a new file with the exact number of sheets as the original. Ensure each sheet names are the same. 2. Cut and Paste each sheet. Make sure you 'Paste special' limiting the content being placed in the new file to text, numbers, date time, formulas and formats. 3. If you have images in the file. Recreate / Save using another package. As mentioned I used GIMP. 4. Insert new copies of the images into file. *Don't* cut-and-paste objects from the old file. 5. If you have any lines, text boxes and artwork; recreate them from new. During this process... - Save as a new version (+tabs, +data, +images, +other objects) following each step. - Test each version thoroughly before proceeding. - Only add one object at a time, so if something goes wrong you can isolate the problem component. - To check it is not a bug try and recreate with a fresh file. A couple of quick notes that may be valuable to others... - ODS files are archives. Use an archive facility to extract the data inside. Inspect the contents in the folders to see what is different. - On every 'Save as' the file size changes. This is not due to changes in the file contents, but rather in changes in how the components of the file is compressed/archived. If you open a file, add objects then save, the file size with be so big. Open that file and Save as a new name and the file will be a different size. If you extract the files the contents of all the files and directories are identical. It is just the internal archive facility in LO will decide the best compaction routine based on what it encounters. - The content.xml file can be quite large and has no internal end-of-line characters. This make it difficult to open and be parse by various text editors, xml viewers and comparison facilities. To insert a EOL character after the end of each tag (i.e. ), I used the following command in the terminal (requires Linux). cat content.xml | sed -e 's//\n/g' content_with_linebreaks.xml cat just spews the content of the text file to the standard output. I then pipe it to sed, where I used regular expressions to find '' and replace every instance of it with '\n'. I then compared the contents with Diffuse. Snip +1 I wonder how the images got corrupted, interesting. Cheers Simon Simon Cropper Principal Consultant Botanicus Australia Pty Ltd PO Box 160, Sunshine, VIC W: www.botanicusaustralia.com.au -- Jay Lozier jsloz...@gmail.com -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted