Apache OpenOffice (AOO) Bugzilla – Issue 124717
Embedded GDI Metafiles replaced by "Read Error" box after File - Save
Last modified: 2019-10-12 17:12:17 UTC
With "AOO 4.1.0 RC3 – English UI / German locale [AOO410m17(Build:9763) - Rev. 1586584 2014-04-11 08:56:50]" on German WIN7 Home Premium (64bit)", “historic” 4. User Profile used for all predecessor versions and 4.1-dev Versions before I currently have lots of problems with pictures (mostly GDI Metafiles, sometimes .jpg) vanish and become replaced by a rectangle with correct picture dimensions and message "Read Error". It seems that the problem mostly appears when I save the document. Unfortunately the problem currently seems limited to confidential complex documents with lots of OLE objects, sections, tables, pictures, ... , and it only appears after lots of edits. I am working on a solution how to make the problem reproducible. Result looks similar to "Issue 114361 - "Read Error" with embedded images after saving in Writer", but I am pretty sure that I did not observe the problems with 4.0.0 and 4.0.1
Discover bug -> Report in Bugzilla -> Make it reproducible: the frustrating way Discover bug -> Make it reproducible -> Report in Bugzilla: the efficient way :)
I forgot to mention: I see the problem on 2 WIN7 PC with different 4.1-dev versions. (In reply to Edwin Sharp from comment #1) You are wrong. Sometimes it is difficult to make a bug reproducible, and users might doubt whether there is a problem with the own PC or the software so that they should report a Bug. In these cases it is useful if a Bug report already does exist. This will encourage users who see that the problem is not limited to their PC to share their experience in Bug reports, what will increase chance that the bug will become reproducible. As an Example see "Issue 17124 - hyperlinks destroyed, dataloss "
The ultimate purpose of this site is fixing bugs. An irreproducible bug has practically almost zero chance of being fixed. Time is our most precious resource. -> Allocating time to issues with very little chance of being fixed (since currently irreproducible) is wasteful.
Can not reproduce AOO410m18(Build:9764) - Rev. 1589052 2014-04-22 12:11 - Linux x86_64 Debian
(In reply to Edwin Sharp from comment #4) I will tell you if I need advice.
This is Bugzilla, not Craigslist. If users will submit an issue for every unexpected behavior they encounter "to share their experience" we will have chaos. I will be happy to confirm this bug (if a bug) and see it fixed. As long as this is impossible, the issue is irreproducible.
Created attachment 83346 [details] Sample Document with lost GDI-Metafile This document is a part of an affected document, unfortunately only a result, I can't tell how that happened. Mostly affected are GDI metafiles with contents pasted from Calc, but I also saw that problem in the same class of documents with photos.jpg. Until I saved it it showed the replacement boxes, now after reopen boxes have vanished Typical context if the replacement box "Lesefehler" (read error) appears are * Difficulties to save the document, ** error message "Started with wrong parameter" or similar (I think I should be able to get the correct complete text, soon) ** Saved with new name, but OOo does not remember the new name and the path * Lots of pages inserted * Writer Tables destroyed, on each page only shown repeated Table Heading and 1-2 table rows. * Other strange effects All those additional effects normally will have vanished when I reopen the document, only replacement boxes sometimes remain, most times also will have disappeared, so that nothing of the GDI metafile remains. I saw and see the problem on 2 WIN7 PC with different 4.1.0-dev and 4.1.0 release versions. I can send a document with metafiles "sample_dev.odt" by mail to a developer, I don't like the scenario that my customer finds my report in the internet
Well, I am some closer to the roots. In my archives I found a document what will show the GDI with 4.0.0 and the replacement box when opened with 4.1.0. Still now way to get to there reproducible and reliably, but may be an expert can do some conclusions from the different view in 4.0 and 4.1? I can send the documents by E-Mail to a developer (I don't want that they will be found by Google).
(In reply to Rainer Bielefeld from comment #8) > Well, I am some closer to the roots. > In my archives I found a document what will show the GDI with 4.0.0 and the > replacement box when opened with 4.1.0. Still now way to get to there > reproducible and reliably, but may be an expert can do some conclusions from > the different view in 4.0 and 4.1? > > I can send the documents by E-Mail to a developer (I don't want that they > will be found by Google). Rainer, please send the sample documents to me (orw@apache.org). I will have a closer look.
I sent to Oliver-Rainer Wittmann a test kit with 3 documents: 2gdilost_Confidential.odt Here the GDI metafile is lost 1showsgdireplacement_Confidential.odt With 4.1.0 for me shows replacement box, 4.0.0 shows GDI metafile (Copied Spreadsheet contents) 0gdivisible_Confidential.odt With 4.1.0 for me GDI metafile still is visible. With a little luck you should be able to replace the metafile by the "Lesefehler-box" with proceeding similar to: 1. Delete "Rainer Bielefeld" signature (blue handwriting, might be missing because linked, you find it on page 7 below the grey table) 2. Delete a word somewhere 3. Type a word somewhere 4. Save under new name 5. Search document for "Auszug" and check whether GDI metafile below still is ok 6. Go got step 2. and repeat steps I did my tests with "AOO 4.1.0 Release – German UI / German locale [AOO410m18(Build:9764) - Rev. 1589052 2014-04-22 11:43:54]" on German WIN7 Home Premium (64bit)", “historic” 4. User Profile used for all predecessor versions. The test kit documents contain linked pictures what will not be available for you, I hope that that does not interfere the test results.
Due to the mail problems on apache.org I did not received until now. Rainer: may be you could send it directly to orwittmann at googlemail dot com Note: I found the root cause for issue 114361 and I am working on a solution
(In reply to Oliver-Rainer Wittmann from comment #11) > Due to the mail problems on apache.org I did not received until now. > Rainer: may be you could send it directly to orwittmann at googlemail dot com > > Note: I found the root cause for issue 114361 and I am working on a solution Please read: ... I did not received the documents until now. ...
(In reply to Oliver-Rainer Wittmann from comment #12) > Please read: ... I did not received the documents until now. ... Might be size related, total zip 19MB? I will try 3 single documents (<7MB) each to both addresses
Relation to "Issue 124847 - image paste problem" currently is only a very vague suspect. I checked the unzipped sample documents I sent to Oliver-Rainer Wittmann. The GDI metafile copied from spreadsheet in 0gdivisible_Confidential is a picture 20000AF5000070E900003CDB0FB00147.svm. In 1showsgdireplacement_Confidential it has been renamed to 20000AF5000070E900003CDB0FB00147.bmp, but seems to have still the svm contents (looks similar in WynWrite, exactly the same size. Also a second .svm has become renamed to .bmp. In 2gdilost_Confidential 20000AF5000070E900003CDB0FB00147.svm is lost in folder "Pictures".
Well, now I think Issue 124847 IS related. File SurfM contains .svm with extension .bmp, and . bmp are missing in SurfMa (Folder "Pictures").
I can confirm with the confidential provided document the "Read Error" replacement image for one of the embedded Metafile graphics. More or less the same root cause as issue 114361 - embedded graphic file changed its name on save operation.
(In reply to Rainer Bielefeld from comment #15) > Well, now I think Issue 124847 IS related. File SurfM contains .svm with > extension .bmp, and . bmp are missing in SurfMa (Folder "Pictures"). I did not found the mentioned files 'SurfM' and 'SurfMa' at issue 124847. Is it the correct issue number?
(In reply to Oliver-Rainer Wittmann from comment #17) > (In reply to Rainer Bielefeld from comment #15) > > Well, now I think Issue 124847 IS related. File SurfM contains .svm with > > extension .bmp, and . bmp are missing in SurfMa (Folder "Pictures"). > > I did not found the mentioned files 'SurfM' and 'SurfMa' at issue 124847. > Is it the correct issue number? I found the mentioned files at issue 124848. Is this the issue which was meant?
Today I found a document from 2010 I can publish without problems That document survived several edits with server installation of "AOO 4.0.1 – German UI / German locale [AOO401m3(Build:9712) - Rev. 1520285 2013-09-05 13:52:01]" on German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile Steps how to reproduce the problem: 1. Unzip a copy of sample document funktionsbeschreibung_401_002.odt, -> check folder "Pictures": contains 4x SVM 2. Open "funktionsbeschreibung_401_002.odt" with 4.1.0 -> save under new name without any edit -> Close document 3. Unzip step 2 result document -> check folder "Pictures": SVM files now have name extension .bmp, but contents seems to be the same as with extension .svm and size has not changed I decided to switch back to 4.0.1 and see this one (together with issue 124848 and may be other related ones) as a 4.1.1 showstopper. I have hundreds, may be thousands of such documents in use, and I think many users might suffer from that dataloss. Although I can't calculate the number of affected users I consider this problem very serious, may be a public warning is necessary, at least immediately after we have a fix.
*** Issue 124893 has been marked as a duplicate of this issue. ***
*** Issue 124848 has been marked as a duplicate of this issue. ***
I think this one is a 4.1.1 showstopper
Created attachment 83415 [details] where figures vanished
Currently, I can only reproduce the 'loss of a picture' due to a save action - as reported issue 114361. For this defect I have a fix available in my local development environment. The general 'loss of a picture on a save action' issue is not new, but the 'loss of a *.svm picture on a save action' has been introduced in version 4.1.0 with the changes made for issue 15508. Workaround: After having saved the document which causes the 'loss of a picture' directly re-load the document (Menu File - Reload) ----- Until now, I am not able to reproduce the 'loss of a picture' by just working this the document - as TAB had reported in issue 124848 using version 4.0.1 TAB: May be you are able to provide steps which reliable reproduce the 'loss of a picture by working with the document'. Could you please also check your OpenOffice settings, if you had set a certain option which is not set by default which might have impact on this. Thanks in advance.
Created attachment 83419 [details] Sample Source Document (In reply to Oliver-Rainer Wittmann from comment #24) With server installation of "AOO 4.1.0-dev – English UI / German locale - [AOO410m14(Build:9760) - Rev. 1583418 2014-05-03]" on German WIN7 Home Premium (64bit)", own separate user profile: I was able to provoke the "Imageloss when edit" problem with a writer document and spreadsheet document contents pasted as GDI meatafile. Unfortunately the problem seems to depend on a partiuclar order and kind of actions, so I failed to reproduce the success. 1. Open source.ods 2. Select A1:G35 -> control+C for copy 3. Menu 'File -> New -> Writer Document -> Zoom Optimum 4. Longclick Paste Icon -> As GDI Metafile 5. Vertical Scroll Slider to bottom of scroll bar -> Click below invisible Metafile > Focus scrolls -> Caret flashes 6. Type <blank> - <enter> 7. Save document as target000.odt 8. <blank> -> Scroll Slider to bottom of scroll bar -> Close (and save) document with Window top richt close X 9. Reopen Document 10. click below invisible Metafile 11. Type <blank> - <enter> -> Save Icon to save 12. Scroll most down -> most up Bug: Image is lost For me that worked 4 times successful. I can't tell whether all steps will be required and whether that means 100% reproducible, it seems some smaller derivations will make fail reproducion. In real life with such GDI metafiles in text documents I saw that every few minutes.
"orw" committed SVN revision 1595851 into trunk: 124717: do not mark *.svm graphic files as *.bmp graphic files
(In reply to Rainer Bielefeld from comment #25) After my step 12 a menu 'File -> Reload' will bring back picture
(In reply to Rainer Bielefeld from comment #25) > Created attachment 83419 [details] > Sample Source Document > > (In reply to Oliver-Rainer Wittmann from comment #24) > With server installation of "AOO 4.1.0-dev – English UI / German locale - > [AOO410m14(Build:9760) - Rev. 1583418 2014-05-03]" on German WIN7 Home > Premium (64bit)", own separate user profile: > I was able to provoke the "Imageloss when edit" problem with a writer > document and spreadsheet document contents pasted as GDI meatafile. > Unfortunately the problem seems to depend on a partiuclar order and kind of > actions, so I failed to reproduce the success. > > 1. Open source.ods > 2. Select A1:G35 -> control+C for copy > 3. Menu 'File -> New -> Writer Document -> Zoom Optimum > 4. Longclick Paste Icon -> As GDI Metafile > 5. Vertical Scroll Slider to bottom of scroll bar -> Click below invisible > Metafile > > Focus scrolls -> Caret flashes > 6. Type <blank> - <enter> > 7. Save document as target000.odt > 8. <blank> -> Scroll Slider to bottom of scroll bar -> Close (and save) > document with Window top richt close X > 9. Reopen Document > 10. click below invisible Metafile > 11. Type <blank> - <enter> -> Save Icon to save > 12. Scroll most down -> most up > Bug: Image is lost > > For me that worked 4 times successful. I can't tell whether all steps will > be required and whether that means 100% reproducible, it seems some smaller > derivations will make fail reproducion. In real life with such GDI metafiles > in text documents I saw that every few minutes. Thx for the provided steps to reproduce the 'loss of a picture'. With these steps the 'loss of a picture' due to a save action can be reproduced. I hope TAB can provide a comparable description to reproduce the 'loss of a picture' by just editing the document.
(In reply to Oliver-Rainer Wittmann from comment #28) I think with same source document similar tests as in comment 25 also reproduced a picture loss with a simple <enter>, at least the picture in 1 test disappeared immediately after an <enter>. But the problem might be that the picture not always disappears immediately, might be necessary to scroll or to wait. So it is difficult to decide what exactly the loss has caused - except you do with very much time. If possible I will do some additional tests with available documents to narrow down the moment of picture loss and it's roots. I hope that I will find out that all that depends on the problem you fixed.
(In reply to Rainer Bielefeld from comment #29) > (In reply to Oliver-Rainer Wittmann from comment #28) > I think with same source document similar tests as in comment 25 also > reproduced a picture loss with a simple <enter>, at least the picture in 1 > test disappeared immediately after an <enter>. But the problem might be that > the picture not always disappears immediately, might be necessary to scroll > or to wait. So it is difficult to decide what exactly the loss has caused - > except you do with very much time. If possible I will do some additional > tests with available documents to narrow down the moment of picture loss and > it's roots. I hope that I will find out that all that depends on the problem > you fixed. I will do some further tests. The fix which I had provided for issue 114361 only fixes the 'loss caused by a save'. The fix for this issue corrects a code change which had been made for 4.1.0 - namely for issue 15508. TAB had reported in issue 124848 that a 'loss caused by editing' also occurs in 4.0.1. Thus, this fix can not solve the defect which TAB had observed. That a 'loss caused by editing' does not appear immediately, but after a certain wait time makes me think that a certain OpenOffice setting/option might impact the defect - e.g. auto-save time, memory settings, ... (I do not know - it is just a guess)
The problem does not appear if you save and work with the file as Word document
We currently have no report that explicitly excludes that the problem might be related to save actions, Due to my experience (I did some more tests yesterday) there is no problem without a save before. I am nearby 100% sure that I never saw that problem with a new document and inserted pictures before first save. There might be some time several edits between the appearance of the root of the problem (.svm renaming to bmp, disappearing .bmp) and the moment where the problem becomes visible. Because I think that it will be difficult to exclude the possibility of additional "non-save-problems" with systematic testing I now try "AOO 4.2.0-Dev – German UI / German locale [AOO420m1(Build:9800) - Rev. 1595858 2014-05-20 1]" on German WIN7 Home Premium (64bit)", “historic” 4. User Profile used for all predecessor versions. First test look fine, I was not able to reproduce problems I confirmed here.
Created attachment 83439 [details] 2 pics disappeared, p.5
I still see a picture loss - read error problem with "AOO 4.2.0-Dev – German UI / German locale [AOO420m1(Build:9800) - Rev. 1595858 2014-05-20 1]" on German WIN7 Home Premium (64bit)", “historic” 4. User Profile used for all predecessor versions. But the test conditions ave very different, I will have to do some more research to find out whether that problem is a different aspect of this one or has completely different roots. Hand with the new problem here I am absolutely sure that I did not save the document before the picture became lost. And so I think that I observed a different bug than Issue 124717 (but might be related)
(In reply to TAB from comment #33) I urgently recommend only to post samples and comments here if they probably are related. Without explication how your document lost those pictures this sample document might be not very useful.
I will submit a new Isssue concerning my .png related problems as soon as I know how to make that reproducible and we will see whether and how that is related to this one. I did not observe the GDI related problem ans more, so I think we should close this one FIXED and investigate other (possibly related ) problems in separate issue reports.
(a) Due to Comment 36 I submitted "Issue 124946 - Embedded PNG Pictures replaced by "Read Error" box" (b) I close this one due to successful verification of fix for GDI loss problem after save. (c) we urgently need more tests because we can not be 100% sure that "Issue 124848 - graphic/OLE read errors" and "Issue 124848 - graphic/OLE read errors " really are DUPs. Reporters should test with 4.2-dev with included fix for this one and report their results in those reports if the problem still appears. @orw: Of course, please feel free to reopen this one if you think that that would ease fixing process for all aspects of the picture loss problem.
*** Issue 125063 has been marked as a duplicate of this issue. ***
grant showstopper flag, regression and already fixed
"orw" committed SVN revision 1603787 into branches/AOO410: 124717: do not mark *.svm graphic files as *.bmp graphic files
fixed on branch AOO410 for planned 4.1.1 release
@ TAB: Oliver has submitted fix for issue 124717, would you please verify issue 124717 and all related duplicates(124848, 124893, 125063), then change status for these issues? Thanks!
Marking it as fixed based on test result from TAB(Thanks!), see following response via email: Alain Torrens Aug 2 (2 days ago) to me Hello! Build 1614049 works fine! TY
This sure sounds like https://issues.apache.org/ooo/show_bug.cgi?id=59915 which has ruined a bunch of patent docs for me. I will probably have to stop using it cause I can't trust it. When I upgraded today, It also warned of a error to one of my files, not even open at the time, with the GDI error, I could not cut from it so I can't tell you the number. It's a general bug that we cannot cut and past error messages.
@donovan2419: This bug, i.e., https://issues.apache.org/ooo/show_bug.cgi?id=124717 , is supposed to be fixed in version 4.1.1 and it has been verified fixed. If you believe it still occurs with 4.1.1 please insert a comment in the issue page.
Sorry, it happened again! The picture (OLE) was there --good. Then, I read and closed a couple of documents, and the Read-Error occurred. I closed and reopened the file; the frame was empty, without Read-Error message. It could be a memory-management problem, with 12 documents open.
Created attachment 84272 [details] bug in progress
Created attachment 84273 [details] bug finished
Hello! This bug is NOT fixed. It happened to me again, not only with graphic/OLE files, but also with pictures inserted by Insert>Picture>fromFile .emf. This occurred after I split a long document into PartA and PartB. Pictures & graphics disappeared from PartB. Could it be that some linking information remained in PartA as info pertaining to the original file?
More info. 'Graphic cannot be displayed' errors occurred again after I split a document. So, to restore one of these vanished pictures, I loaded it again with the graphic program SmartSketch and... before I could restore the picture through the usual copy& paste procedure (which is how I originally inserted it in my OO document), the picture magically (?) reappeared! I do not understand the inner workings of OO, but YOU might determine from this observation what causes the problem.