Reassigned to Christian.

set to new

Can you please tell me what you've done shortly before the graphics
disappears?
Can you attach the document(before the graphics disappears) to see the
number of graphics, the size of the file, ...

sure. I did rearrange some of the text boxes on other pages to fit 
more nicely on the page and was saving from time to time. At the end, 
I wanted to view the entire presentation to verify the results but I 
realized the missing graphics (not all of them, only some where 
missing).

I re-opened OpenOffice, same effect. Computer reboot, same effect. 
Moved file to a new workstation, also OpenOffice 1.1beta2, same 
effect.

Unzipped the file and directly looked into the Pictures directory, I 
found PNG files in there, but couldn't display them. So I assume, 
they where saved in a broken state.

Then I reinserted the graphics into the document, after a while same 
problem. So it is reproducable. I will attach the presentation so you 
can take a look at it.

Created attachment 7364 [details]
presentation

I have the same problem with OOo 1.1 RC2.  I've found that if I unzip
the *.sxi file for a presentation in which the graphics are still
present, I can view the images that are unzipped and put in the
/Pictures directory.

However, if I do the same for a presentation in which the graphics
have disappeared, the images are corrupted (or at least kuickshow
won't open them).

Perhaps impress isn't saving the images properly?

I run SuSE 8.2 on a PC.

Damien

Hm. Should this bug ever hit you again, could you please check free disk space on the 
temp dir (the place used by the office is listed in the "Tools->Options" dialog, below 
StarOffice->Paths, the entry is named "Temporary files")? The office spools 
extracted zip package content there, and if the volume is full there, strange things 
happen.

I'm running into a similar problem with OOo 1.1RC3. My wife has a
presentation that uses about 15 graphics (mostly JPG, but some GIF and
PNG as well) on 9 slides. She could insert a graphic on one slide just
fine, and then insert another graphic on a 2nd slide, but when she'd
go back to the first slide the graphic would be gone and only a
placeholder would remain. We could only get 1-2 graphics to "stick"
after saving, closing, reopening, and flipping back and forth through
the slides. I had to reinstall OOo 1.0.3.1 which doesn't seem to have
this problem and worked just fine with the graphics.

BTW, we're running Windows XP, and there's plenty of free disk space
on our hard drive (~4GB).

Just had this problem using RC3.

Previously had developed a sxi file with 100+ bitmap (PNG) graphics
included in OOo 1.0.  When they were inserted into the document the
link checkbox was off.

Opened/closed doc several times with OOo1.1, printed etc, over several
days.  No problems encountered.

Then the problem:

- Executed OpenOffice 1.1 Presentation package
- Selected Open existing presentation
- Double clicked my sxi file.  (File size is 657K, 89 pages)
- Since document was left at last page clicked the button to move all
the way to beginning of document
- Clicked page forward twenty times to page I wanted to edit.
- Clicked on page.
- Clicked on graphic (A PNG file which was originally inserted with
link checkmark off).
- Pressed delete key
- Inserted new graphics (PNG) on same page
- Moved graphic into position using mouse.
- Selected File - Print
- Selected Pages, please note:
    Only printing the single page I'm working with, page 20
    Printer Type is set to Apple LaserWriter 16/600 PS
    Printer Location is set to print File
- Pressed Ok
- Received warning about document containing transparent objects,
Clicked yes to allow transparency to be reduced
- Waited for printing operation to finish
- Deleted graphic again
- Saved document
- All other graphics disappeared in the document only.  It appears
that the file size is large enough (590K) to still contain graphics.
- Reinsert PNG graphic (probably any edit here will do....)
- Save document again.
- File size is now 96K.  Almost all graphics lost, see note below.

Note:  I had inserted five or six small graphics (PNG files) at the
beginning of the document.  I had continuously copied within the
document the same small graphics to various locations/pages.  Those
small graphics are still in the document after the problem noted
above.  Does multiple references to the same graphic mean the problem
does not crop up?

Other info:

Windows 2000, no service packs installed.  

Plenty of hard drive space (17+ GB remaining) on drive where temp as
described (in other comments per 16297) sits.

1GB ram.


Hope all this helps, I just spent 2 hours trying to exactly duplicate
the problem and then write it up.  For once I may have gotten it, or
at least I hope so.

*** Issue 15322 has been marked as a duplicate of this issue. ***

*** Issue 13817 has been marked as a duplicate of this issue. ***

*** Issue 19471 has been marked as a duplicate of this issue. ***

The prolem is still present in RC4.  I will add an additional sample
file.  In this one the images applear to be completely removed from
the file.  What I mean is that if you unzip the file you won't see any
images at all.  Furthermore, the XML has the xlink part of the <draw>
tag removed.

Should be:
<draw:image ... xlink:href="..."/>

Instead, it is:
<draw:image ... xlink:href=""/>

Since embedded graphics are basic functionality, I'll set the priority
level of this issue to P2.

Created attachment 9291 [details]
Sampe file where the images have gone missing and the <draw> tag has seen the contents of the xlink: filed removed.

*** Issue 17945 has been marked as a duplicate of this issue. ***

*** Issue 18122 has been marked as a duplicate of this issue. ***

*** Issue 19576 has been marked as a duplicate of this issue. ***

*** Issue 18804 has been marked as a duplicate of this issue. ***

*** Issue 17257 has been marked as a duplicate of this issue. ***

Hi Thorsten

You're working on this bug.
Here is the issue of the bug.
dcarrera and I set some bug to duplicate of this bug.

Yep, will investigate ASAP.

*** Issue 15847 has been marked as a duplicate of this issue. ***

*** Issue 19617 has been marked as a duplicate of this issue. ***

I change the target to OOo1.1.1 .
I think OOo2.0 is too late for this bug.

is here a connection to issue 19040 ?

*** Issue 11182 has been marked as a duplicate of this issue. ***

*** Issue 17379 has been marked as a duplicate of this issue. ***

*** Issue 20523 has been marked as a duplicate of this issue. ***

Just installed OOo 1.1 rc5 to replace rc3 where the problem first 
appeared for me.  Problem still exists in rc5.  Open the 
presentation, all graphics (jpgs and pngs) are replaced by 
placeholders.  SOME of the placeholders subsequently are replaced by 
the proper graphic after about 4 or 5 seconds.  Others remain 
placeholders indefinitely.  Deleting the placeholders and 
reinserting the graphics doesn't correct the problem.  Saving after 
reinserting graphics (with them properly displayed) doesn't help.  
Entering the full path to the graphic when inserting doesn't help. 
 
This is on a linux system (Mandrake 9.1).  No memory shortage, not 
in RAM nor on HDD. My /tmp is not full.   

My workaround is to link (rather than embed) the pictures.   For stuff
like data charts or figures drawn with external tools, linking is
convenient anyway.  No problem in 1.1beta1, so probably will be okay now.

I may have found a key source/location for the problem.  I am using 
1.1.0rc5.  This problem first showed itself to me with 1.1.0rc3 - it 
continues in rc5.  I have found that the issue DOES exist for 1.0.3 
as well if using a presentation produced by rc3 or rc5.   
   I gave a presentation today.  To succeed without losing most of 
my images (replaced by placeholders) I had to abstain from saving 
the presentation.  I deleted the placeholders that appeared in place 
of a number of jpegs and png files and reinserted the same images.  
I did not save the file and they remained in place (I carried my 
running laptop to the conference room within which I was presenting 
and went from there).  I conducted my OO 1.1.0rc5 presentation 
without incident and THEN saved the file.  I haven't seen the error 
that appears before so it may be unrelated but I get: 
 
Error loading BASIC of document 
file:///home/praedor/OpenOffice.org110/user/basic/dialog.xlc 
General Error 
General input/output error 
 
I select OK and it reappears once more.  I hit OK and the 
presentation saves but the images vanish and are, once again, 
replaced by placeholders.  I did have the vanishing image problem 
even without having the error message above appear.  This may be 
related to the fact that the presentation has passed from 1.1.0 to 
1.0.3, then back to 1.1.0.  In any case, as soon as I save the file, 
images vanish to be replaced by placeholders. 
 
These placeholders remain in lieu of images even if I reopen the 
presentation in a previous (v1.0.3) of OO.  Something in saving the 
file is borking the images. 

*** Issue 20734 has been marked as a duplicate of this issue. ***

All of you: are you opening your presentation via the presentation
autopilot? Then we probably have the cause for this problem (the
autopilot sets an empty password on the document, which, when saved,
leads to a document with encryption (thus the garbage in the picture
files), but empty password. A second bug in impress then messes up the
state irrevocably).

Christian, please have a look on the encryption probs for impress.
This bug should then be fixed, too.

well, that is a good question. I think, most of the time - yes,
because its the default when you launch impress. I know, that I also
sometimes double-click on the presentation, but I really can't tell
the percentage.

I agree with the password being an issue, I have seen this from time
to time popping up during the load of the document (enter password)
even though I didn't have one assigned.

Let me know if I can do some testing.

Ronny

About 95% of the time I create a document via the presentation autopilot.

About 85% of the time I tend to open a pre-existing document via the
presentation autopilot.

Unfortunately, in neither case have I noticed a correlation between
the autopilot and the disappearing graphics.

I too on rare occasions have been asked for a password that I never
set.  But, I seem to remember that those occasions were directly
preceded by a crash in the software.  I could be wrong about that. 
But, what makes me think it is true is because a crash followed by a
request for a password that was never set is kinda tramatic.

I have seen this most often in password-protected documents (not only
Impress, I saw it in Calc too), so I think that this password
hypothesis is on the right track. 

duplicate to #trk112706# and #bt4851957#

André, please fix the password issue in the autopilot. Christian
Günther should try to reproduce this bug by using the autopilot with
and without your fix. I like to be sure that this bug is realy fixed
for pp1!

I did it both ways. Can't remember when the password was asked and
when not, but as I read about it - I think my presentation was messed
up after wanting a password from me.

I think you found the "root bug" - great work, Thorsten "Sherlock"
Behrens.

Accepted.

Binary graphics disappear very easily in openoffice draw ALSO, 
therefore without any password nor with autopilot (actually, 
reproduced very often with StarOffice 6.0 + patch in StarDraw). 
 
Therefore this doesn't seem to be a regression, and I don't 
think it's a presenter bug. (my father use exclusively 
StarDraw to layout digital pictures for printing, and when 
the document becomes too large, several pages can have 
their pictures destroyed. He doesn't use password at all.). 
 
CC 
 

In two files (sd/source/ui/app/sdmod1.cxx and
sd/source/ui/dlg/dlgass.cxx) I added guards against empty passwords. 
When the passwords are empty they are not set.
Now the QA has to find out, whether this really fixes the bug.

*** Issue 20235 has been marked as a duplicate of this issue. ***

Please check.

Reassigned to Christian for verification.

*** Issue 19617 has been marked as a duplicate of this issue. ***

set to verified at least in CWS softdist01 

set to verified at least in CWS softdist01

I change the title of this bug because the fix for this bug fixes only
one part of the missing graphics. There is another (internal) bug
which fixs the other part of the graphic bug so that the bug is fixed
completely.
The target of the other bug is also OOo 1.1.1

Reassign issue to AF

Hi Christian

this is included in 645m12, please check. Seto resolved fixed. 

changed to Christian

*** Issue 22219 has been marked as a duplicate of this issue. ***

If this bugs not only in presentation (but mostly in presentation) it
means the better component for this is framework ? 

utomo > thorstenziehm:
is the 645m12 same as 1.1.1 or OOo1.1fix1 ? 

This bug only occures, when you use the Impress-Autopilot. So this is
a impress/draw issue.
This bug will be included in 1.1.1. When this will be integrated into
ooo111pre I don't know. This is an timing issue in release engeneering
team. If you have questions about timeframe of ooo111pre see the mail
from Martin Hollmichel at releases@openoffice.org.

=> I delete my name from CC-list.

I do have 1.1.0 (don't know how to get the Rx, with RH9 and I get the
same problem. I noticed the need for a password (which I did not set).
I have read from the issue history that the password problem might be
related and the usage of the autopilot. 
I disabled autopilot, saved the file (password unmarked), reopened in
normal way, replaced some of the missing objects from an earlier
version of the file, but after saving and reloading file, all but the
last object I inserted were missing again.
If this helps, fine.

The fix is integrated in OOo1.1.1 in Sols, Lin, Win.
OOo1.1.1 will be available soon.
Please reopen the issue if the bug still occures in OOo1.1.1

*** Issue 18977 has been marked as a duplicate of this issue. ***

*** Issue 18977 has been marked as a duplicate of this issue. ***

*** Issue 20827 has been marked as a duplicate of this issue. ***

*** Issue 20827 has been marked as a duplicate of this issue. ***

*** Issue 21647 has been marked as a duplicate of this issue. ***

*** Issue 23154 has been marked as a duplicate of this issue. ***

*** Issue 10624 has been marked as a duplicate of this issue. ***

I do not have the permissions to re-open this issue, but I believe it needs to
be re-opened. We are having this problem in OOo Writer and it is occuring on
simple opening and savings of documents. We don't need to be using any
autopilots or anything, it's a fundamental issue and it appears to be across all
of OOo (i.e. it's a "framework" issue).

I hate to be the bearer of bad news, but this is a show stopper bug for us in
1.1.1rc as well. We had been doing our integration with 1.1.0 (and fighting with
this bug) and were told that this would be fixed in 1.1.1, so we tried the RC
and it is still a bug for us that prevents us from using OOo with our application.

Specifically, we are using the MailMerge service as part of a macro and it
cannot open the documents even with this fix in place. It seems that an empty
password is still being set in the document, and the fix that was put in place
to address this issue (to ignore it when reading in a document) doesn't help
when using the MailMerge service (which still throws an exception trying to open
the file... which causes OOo to hang because of another bug...).

So, here's what we do... We edit the document and make a change. If we do a
File->Save As... and turn off the "Save with password" box, then it saves
without the password and we can do MailMerges. However, if we open up the
document again and make another change, and just do a File->Save or press the
"Save" icon on the toolbar, then it quietly saves the document with the password
set again, and MailMerge dies. We have decided that our user base is not
sophisticated enough to use "Save As..." and click the box every time they edit
a document, and that we can't release until we have a solution for this...

Isn't there some way of stopping the "Save with password" property from turning
itself on in the first place? This would fix the problem for all cases rather
than trying to ignore it when loading documents in certain contexts...

I have written a workaround in 1.1.1rc that will allow us to go to Beta with our
application, but I'm still hoping for a fix in 1.1.1 (fingers crossed :-). What
I did was set a listener on the document that waited for an "OnSaveDone". I then
used the XModel's getArgs() method to get the document's arguments. If the
"Password" property is set and it has a length of zero (0), I get the URL
property, and build a new property set that excludes the "Password" property. I
then use the URL and the expurgated version of the property set as an argument
to XStorable's storeAsURL() method.

If I subsequently open the document and make any changes (Note: I always invoke
the document through my macros, so I have control over it... and I can always
set my listener), the "phantom password" (as I have started calling it) is set
again before the user does a save of the document (of course, if they do a Save
As... they need to make sure to uncheck the "Save with password" box or they'll
be prompted to set a password), and I have to clear the "phantom password" again.

My suspicion is that the bug is where the PropertyValues sequence is being
assembled for a document (either when it is opened which is my suspicion, or
when a change has been made)... the "Password" property is being created, and
included in the sequence, but the value is, of course, not set.

Is there any way I can re-open this issue (as per my earlier comments)?

I can't reproduce the issue but I reopen it to have a deeper look into it with
the new description from jbotte.

Thanks.

The fix and the bug wasn't a general error in OOo. As I know it was only a bug
with presentations and graphic document and wasn't with spreadsheets or writer
documents.
Please write a new tasks for the category 'word processor'. It is needed to give
some more details. Because we cannot reproduce the problem as you described.
Did this bug exists also in OOo1.1 or only in OOo1.1.1RCx?

The original bug is fixed in OOo1.1.1. 

I set this task to the next target. But I will close this bug, when you give me
a hint, which is the new task ID for your issue.

Add me to CC

We do not get any feedback for this task and I close this task.
If it still exists in other constellation, please write a new task.

closed

Issue 23154 was marked as a duplicate of this issue and related to graphics
randomly disappearing: at some moment the placeholder is displayed with the text
"Read error". After saving and reopening the document, the graphic has
completely disappeared. This morning it concerned 2 embedded png graphics. It is
a 95 page document with perhaps 40 or 50 graphics.

This is a horrible issue reported back in februari 2004 for version 1.1. I can
hereby confirm you that it remains in 2006 OOo 2.03. The problem is that this
issue is very hard to reproduce. Neverhteless, this issue should not be closed
as it is not solved. If ever I manage to reproduce this error, I will provide
the details.

After commenting on this issue, i was very surprised about the summary of this
issue. Indeed, disappearance has been linked to some pasword issue. I need to
add that I observed the issue on an odt  document where no pasword was ever set.

Hi ftack,

since 1.1. many core changes were done in OOo graphics project.
If you can reproduce the problem, please create a new issue and write down the
the reproducable scenario. Only if you realy think, that this is exactly the
same problem, please reopen this issue.

Thanks,
  Thorsten