Apache OpenOffice (AOO) Bugzilla – Issue 8634
Unrecoverable error has occured, PNG in writer doc
Last modified: 2013-08-07 14:43:23 UTC
When opening the attached SXW document and unrecoverable error occurs. The document has been cut as far as I can, It only has one png image in it now - and that is a link which isn't there, the error is the same if the PNG file in the link exists. If I recreate the document from nothing (rather than cutting to nothing) the error does not occur. Unfortunatly I can't run "diff" on the extracted contents becasue it's @#$%ing XML and although text it's not formatted in lines.
Created attachment 3304 [details] writer doc with error
James, thank you for using and supporting OOo. When you cut down the file, did you do it by hand, or did you somehow open the file? While we appreciate short and isolated test documents, documents that crash OOo can be attached without any modifications. Can you reproduce the situation that created the corrupted Writer file in the first place?
> When you cut down the file, did you do it by hand, or did you > somehow open the file? Using the editor of OOo writer. It's starts as an SO5.2 sdw file. Open in OOo, save as SXW, reopen in OOo and the error every time. > While we appreciate short and isolated test documents, documents > that crash OOo can be attached without any modifications. Trust me, you don't want any more than a piece of the document that causes the error. Does it not cause an error? > Can you reproduce the situation that created the corrupted Writer > file in the first place? I can reproduce it every time with this one data file. I figured with a verbose flag set in the code and a keen eye you would see why, if not what to do, instantly.
James, thanks for the update. Please attach the original SO5 document. That document is needed for us to get the full picture of what is happening.
Created attachment 3354 [details] StarOffice 5.2 version of error file
The 5.2 SDW file from which the SXW was saved. If I change the size of the image then save as SXW, then reread, a dotted line in the right margin appears. This was a "cut mark" from the full book but is invisible until saved and resumed as SXW. In itself this is of course unimportant but any "An unrecoverable error has occurred" is not very satifactory - at least say: "the file you are reading is corrupted" and not call abort() - particluary as the data file was writen by OOo itself.
Thanks for your patience James. I want to confirm the sequence of events. 1. Open error.sdw 2. Save as OOo text document. Is this correct?
Thank for the additional attachments, James. Duplicated on Win NT 4.0 SP6a, OOo 643. Saving the attachment "error.sdw" as a OOo text file creates an invalide OOo text file that will not load ( you must close the doc then reopen it, a File->Reload works ). OOo has a maximum relative height percentage of 100, but the export file contains a relative height percentage of 106. The offending tag style:rel-height="106%" When OOo tries to load a file with the above tag, it generates: Error loading document file:<path to file> Read error. Error reading file.
Yes, it's the size. And it's worse than I originally thought. I can reproduce this in a trivial file now with any image type, just use the mouse to stretch, then save, exit, start and resume for the error. Workaround make margins smaller. > OOo has a maximum relative height percentage of 100 I think an image should be allowed to go over margins, that's what "anchor to page" is all about. I might also want an image to be partially outside the page. (The page will/should provide a clip path at its edge.) An image might have an excessively large border so to get it to fill a page the blank parts should be allow to go over the edge. Maybe the image need a clip, that's not so easy (not as easy as stretching within OOo) when they are EPSes.
ES->DVO: duplicated in a 644s - insert a graphic - anchor to page + set XY dimensions to "relativ" - stretch the graphic withe the mouse to fit the page - save - reload -> format error
dvo->es, prgmgr, jameslee: Thanks for the nice description & bugdics. That made it easy to find the problem. :-) dvo->jamesless: Regarding "@#$%ing XML [...] not formatted in lines.", you might have a look at tools->options->load/save->general->size optimization for XML If you uncheck the box, the XML will be 'pretty printed'. This may slow down loading/saving of large files though, and also increases file size. dvo->tl: Please have a look at this. The same problem (but for width, rather than height, has already been taken care of by OS. See IBIS bug id #96854# and #96980#. The API limit for loading is: sw/source/core/layout/atrfrm.cxx, #572 If this is changed to match the same line for the MID_FRMSIZE_REL_WIDTH case (#582), loading of the document should work fine. I don't know which changes in the UI would be suitable, though.
Set OS to ALL.
Platform set to ALL.
Fixed in /cws/so-cwsserv06/apps01 Files changed: sw: atrfrm.cxx 1.36.86.1 frmpage.cxx 1.33.2.2.22.1
.
verified
ES: ok in 644m4s4