Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Unrecoverable error has occured, PNG in writer doc | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | jameslee <lista> | ||||||
Component: | code | Assignee: | eric.savary | ||||||
Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> | ||||||
Severity: | Trivial | ||||||||
Priority: | P2 | CC: | issues, oooqa | ||||||
Version: | OOo 1.0.1 | Keywords: | oooqa | ||||||
Target Milestone: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
Developer Difficulty: | --- | ||||||||
Attachments: |
|
Description
jameslee
2002-10-23 10:55:52 UTC
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 |