Created attachment 64838 [details] open this document, then save as When
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
wfm in Version: 5.2.0.0.alpha0+ Build ID: ce3d3f5543e3e132a3473af27aa2c827336add0f CPU Threads: 2; OS Version: -; UI Render: default; Locale : fr-FR (fr.UTF-8)