Bug 52638

Hit Enter too soon, sorry.

When using Save As with a document in Writer, it frequently occurs to me that images are mangled (broken image icon) or absent. This does not happen when I choose Save. I attached a simple test case. Open this document, then choose Save As, enter any filename and type ODF. Now close and reopen the document. Observe that all the images are gone.

Expected result: images do not randomly disappear.

Created attachment 64839 [details]
result after save as

Also, this behaviour is present in the latest release (3.5.5.3) and the latest RC (3.6.0.2)

I do not reproduce with LO 3.6.0.4 nor LO 3.5.5.3 under Ubuntu 11.10.
Please try again with a fresh profile : http://wiki.documentfoundation.org/Faq/General/110

Best regards. JBF

Hm, there was a very similar bug I saw some days ago which was reproducible. But I just can't find it again for now, sorry. Maybe someone else can find it?

Thank you very much for your bug report!

REPRODUCIBLE with
* LibreOffice 3.5.5.3 (Build-ID: 7122e39-92ed229-498d286-15e43b4-d70da21)
* LibreOffice 3.6.0.4 (Build ID: 932b512)
both with German langpack installed, both on MacOS X 10.6.8 (Intel)

Just like the original reporter writes: If I open the sample file (attachment 64838 [details]) and just save it as a new .odt file, then close the file and open it again, all the images are gone.


(In reply to comment #4)
> I do not reproduce with LO 3.6.0.4 nor LO 3.5.5.3 under Ubuntu 11.10.
> Please try again with a fresh profile :

Resetting the user profile has no influence on this issue.
If not reproducible under Ubuntu, maybe a MacOS X-only issue?
-> Could someone else please test on Windows?

@Rainer:
Could you please test if this nasty issue is reproducible on Windows? The test should take only a minute or two, and it is important to know if this issue is MacOS-only or not, so that I can CC the right developer(s). Thank you!

Already REPRODUCIBLE with LibreOffice 3.4.0, German langpack installed, on MacOS X 10.6.8 (Intel). -> Adjusted version information.

NOT reproducible with Server Installation of  "LibreOffice 3.6.0.4 rc  English UI/ German Locale [Build-ID:  932b512] on German WIN7 Home Premium (64bit)

@Rainer:
Thank you very much for testing!

So (cf. comment #4) this seems to be yet another MacOS X-specific bug.

I will try if I can find discover some additional circumstances which are necessary for the bug to occur (or if just using "Save As..." is sufficient); this would probably help the developers to locate the bug.

Already REPRODUCIBLE with LibreOffice 3.3.0, German langpack installed, on
MacOS X 10.6.8 (Intel).

There is a little interesting difference: While LibreOffice 3.4.0 to 3.6.1.2 remove all four images at once as soon as we "Save as" the document, LibreOffice 3.3.0 removes only the first, second, and third image. But when I open the copy created by "Save as" and choose "Save as" a 2nd time, also the last (4th) image disappears; so the 2nd copy does not contain any image at all, just like the "Save as" copies created with LibreOffice 3.4.0 to 3.6.1.2.

-> Adjusted version information.

But what does this "the images are gone" really mean, I mean, at the file level? To check, un-zip both the original sample file (which includes the images) and the "Save as" copy (which misses the images). The results are interesting:

1) The image data is completely removed -- while the original .odt file contains four PNG images in the /Pictures sub-directory, the /Pictures sub-directory is completely missing from the .odt file generated via "Save as". This is correct, because the sub-directory would be just empty.

2) Consequently, in the original .odt file, the four PNG images are listed in /META-INF/manifest.xml, as appropriate, but in the .odt file generated via "Save as", they are missing from manifest.xml. Very consequent so far.

3) But there is something strange with the real contents of the file, the /content.xml sub-file. The section for the 1st paragraph and the 1st image reads as following in the original .odt file (some pretty printing applied):

<text:p text:style-name="Standard">
  <text:span text:style-name="T1">Image 1: </text:span>
  <text:span text:style-name="T1">
    <draw:frame draw:style-name="fr1" draw:name="graphics8"
     text:anchor-type="as-char" svg:width="0.702cm" svg:height="0.702cm"
     draw:z-index="0">
       <draw:image xlink:href="Pictures/1000020000000053000000530A91709F.png"
        xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
    </draw:frame>
  </text:span>
</text:p>

Now you would expect that in the copy generated via "Save as", which misses all images, this would just read very simply:

<text:p text:style-name="Standard">
  <text:span text:style-name="T1">Image 1: </text:span>
</text:p>

Or even simpler, if style T1 does not add any real formatting changes:

<text:p text:style-name="Standard">Image 1: </text:p>

But in reality, it reads:

<text:p text:style-name="Standard">Image 1: 
  <draw:frame draw:style-name="fr1" draw:name="graphics8"
   text:anchor-type="as-char" svg:width="0.702cm" svg:height="0.702cm"
   draw:z-index="0">
     <draw:image/>
  </draw:frame>
</text:p>

So the frame is still there, it even includes the correct width, height, and vertical stacking (z-index) information. And there is also still an image tag -- it is just empty (<draw:image/>).

The same is true for the other three images.

The presense of the empty <draw:image/> tag and of the needless <draw:frame>...</draw:frame> tag is a clear sign of file corruption.

Some further experiments, just to eliminate some possibilities:

(1) Because of the observations reported previously, I hoped that this was some bug with optimization at filesave time, and that un-checking "Options > Load/Save > General > Size optimization for ODF format" would disable the bug. But no success! The only difference is that the needless <text:span text:style-name="T1"> is not removed on the "Save as" action; thus our first paragraph reads:

<text:p text:style-name="Standard">
  <text:span text:style-name="T1">Image 1: </text:span>
  <text:span text:style-name="T1">
    <draw:frame draw:style-name="fr1" draw:name="graphics8"
     text:anchor-type="as-char" svg:width="0.702cm" svg:height="0.702cm"
     draw:z-index="0">
       <draw:image/>
    </draw:frame>
  </text:span>
</text:p>

This does not change our previous results.

(2) Also changing the default ODF file format version from 1.2 extended to 1.0/1.1 does not change anything.

(3) But when we "Save as" the file as .doc file, the images are still present in the new file.

(4) Dito, when we "Save as" the file as .rtf file, the images are still present.

So definitely a bug somewhere in the ODF (.odt) export code.

Roman,

You might also want to look at bug 33853, which for me on Mac is still unresolved.

Alex

please give update of the bug status using latest LibO 4.3.2.2 release