Issue 124717 - Embedded GDI Metafiles replaced by "Read Error" box after File - Save
Summary: Embedded GDI Metafiles replaced by "Read Error" box after File - Save
Status: VERIFIED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: 4.1.0-dev
Hardware: All Windows 7
: P3 Normal (vote)
Target Milestone: 4.1.1
Assignee: Oliver-Rainer Wittmann
QA Contact:
URL:
Keywords: data_loss, regression
: 124848 124893 125063 (view as issue list)
Depends on: 114361
Blocks: 124985
  Show dependency treegraph
 
Reported: 2014-04-21 15:20 UTC by Rainer Bielefeld
Modified: 2015-10-28 17:56 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.1.1_release_blocker+


Attachments
Sample Document with lost GDI-Metafile (15.87 KB, application/vnd.oasis.opendocument.text)
2014-05-06 14:59 UTC, Rainer Bielefeld
no flags Details
where figures vanished (365.10 KB, application/vnd.oasis.opendocument.text)
2014-05-18 20:13 UTC, TAB
no flags Details
Sample Source Document (65.90 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-05-19 11:46 UTC, Rainer Bielefeld
no flags Details
2 pics disappeared, p.5 (81.18 KB, application/vnd.oasis.opendocument.text)
2014-05-20 19:58 UTC, TAB
no flags Details
bug in progress (43.54 KB, image/png)
2014-12-01 19:33 UTC, TAB
no flags Details
bug finished (34.96 KB, image/png)
2014-12-01 19:35 UTC, TAB
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2014-04-21 15:20:43 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
Comment 1 Edwin Sharp 2014-04-21 15:46:04 UTC
Discover bug -> Report in Bugzilla -> Make it reproducible: the frustrating way
Discover bug -> Make it reproducible -> Report in Bugzilla: the efficient way
:)
Comment 2 Rainer Bielefeld 2014-04-21 17:00:08 UTC
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 "
Comment 3 Edwin Sharp 2014-04-21 18:23:42 UTC
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.
Comment 4 Edwin Sharp 2014-05-05 06:20:08 UTC
Can not reproduce
AOO410m18(Build:9764)  -  Rev. 1589052
2014-04-22 12:11 - Linux x86_64
Debian
Comment 5 Rainer Bielefeld 2014-05-05 06:39:35 UTC
(In reply to Edwin Sharp from comment #4)
I will tell you if I need advice.
Comment 6 Edwin Sharp 2014-05-05 07:09:01 UTC
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.
Comment 7 Rainer Bielefeld 2014-05-06 14:59:17 UTC
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
Comment 8 Rainer Bielefeld 2014-05-06 15:38:26 UTC
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).
Comment 9 Oliver-Rainer Wittmann 2014-05-07 06:52:11 UTC
(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.
Comment 10 Rainer Bielefeld 2014-05-07 07:34:20 UTC
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.
Comment 11 Oliver-Rainer Wittmann 2014-05-07 13:15:49 UTC
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
Comment 12 Oliver-Rainer Wittmann 2014-05-07 13:16:50 UTC
(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. ...
Comment 13 Rainer Bielefeld 2014-05-07 16:01:12 UTC
(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
Comment 14 Rainer Bielefeld 2014-05-07 20:50:08 UTC
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".
Comment 15 Rainer Bielefeld 2014-05-07 20:55:01 UTC
Well, now I think Issue 124847 IS related. File SurfM contains .svm with extension .bmp, and . bmp are missing in SurfMa (Folder "Pictures").
Comment 16 Oliver-Rainer Wittmann 2014-05-08 09:42:58 UTC
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.
Comment 17 Oliver-Rainer Wittmann 2014-05-08 10:27:09 UTC
(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?
Comment 18 Oliver-Rainer Wittmann 2014-05-08 10:44:31 UTC
(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?
Comment 19 Rainer Bielefeld 2014-05-11 11:34:21 UTC
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.
Comment 20 Rainer Bielefeld 2014-05-15 04:07:55 UTC
*** Issue 124893 has been marked as a duplicate of this issue. ***
Comment 21 Rainer Bielefeld 2014-05-15 04:17:50 UTC
*** Issue 124848 has been marked as a duplicate of this issue. ***
Comment 22 Rainer Bielefeld 2014-05-15 05:29:45 UTC
I think this one is a 4.1.1 showstopper
Comment 23 TAB 2014-05-18 20:13:32 UTC
Created attachment 83415 [details]
where figures vanished
Comment 24 Oliver-Rainer Wittmann 2014-05-19 09:34:45 UTC
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.
Comment 25 Rainer Bielefeld 2014-05-19 11:46:45 UTC
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.
Comment 26 SVN Robot 2014-05-19 11:50:39 UTC
"orw" committed SVN revision 1595851 into trunk:
124717: do not mark *.svm graphic files as *.bmp graphic files
Comment 27 Rainer Bielefeld 2014-05-19 11:54:35 UTC
(In reply to Rainer Bielefeld from comment #25)
After my step 12 a menu 'File -> Reload' will bring back picture
Comment 28 Oliver-Rainer Wittmann 2014-05-19 12:01:31 UTC
(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.
Comment 29 Rainer Bielefeld 2014-05-19 12:28:36 UTC
(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.
Comment 30 Oliver-Rainer Wittmann 2014-05-19 13:29:47 UTC
(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)
Comment 31 federico 2014-05-20 06:55:11 UTC
The problem does not appear if you save and work with the file as Word document
Comment 32 Rainer Bielefeld 2014-05-20 11:45:38 UTC
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.
Comment 33 TAB 2014-05-20 19:58:28 UTC
Created attachment 83439 [details]
2 pics disappeared, p.5
Comment 34 Rainer Bielefeld 2014-05-20 21:12:02 UTC
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)
Comment 35 Rainer Bielefeld 2014-05-20 21:16:49 UTC
(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.
Comment 36 Rainer Bielefeld 2014-05-20 21:23:53 UTC
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.
Comment 37 Rainer Bielefeld 2014-05-21 05:39:12 UTC
(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.
Comment 38 Oliver-Rainer Wittmann 2014-06-10 07:20:40 UTC
*** Issue 125063 has been marked as a duplicate of this issue. ***
Comment 39 jsc 2014-06-16 09:11:30 UTC
grant showstopper flag, regression and already fixed
Comment 40 SVN Robot 2014-06-19 09:38:36 UTC
"orw" committed SVN revision 1603787 into branches/AOO410:
124717: do not mark *.svm graphic files as *.bmp graphic files
Comment 41 Oliver-Rainer Wittmann 2014-06-19 09:40:44 UTC
fixed on branch AOO410 for planned 4.1.1 release
Comment 42 fanyuzhen 2014-07-14 09:53:03 UTC
@ 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!
Comment 43 fanyuzhen 2014-08-04 06:46:34 UTC
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
Comment 44 donovan2419 2014-08-31 09:29:30 UTC
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.
Comment 45 Andrea Pescetti 2014-09-03 17:09:50 UTC
@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.
Comment 46 TAB 2014-09-17 15:25:17 UTC
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.
Comment 47 TAB 2014-12-01 19:33:29 UTC
Created attachment 84272 [details]
bug in progress
Comment 48 TAB 2014-12-01 19:35:19 UTC
Created attachment 84273 [details]
bug finished
Comment 49 TAB 2015-08-03 19:45:55 UTC
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?
Comment 50 TAB 2015-10-28 17:56:57 UTC
	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.