https://bugs.freedesktop.org/show_bug.cgi?id=52638
Roman Eisele <b...@eikota.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|FILESAVE: images disappear |FILESAVE: images disappear
|when using Save As in |when using "Save As" as new
|Writer as .odt file |.odt file (MacOS X only)
--- Comment #12 from Roman Eisele <b...@eikota.de> 2012-08-29 15:48:16 UTC ---
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.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
