During normal editing at some unknown point details about images are dropped in the written ODP file. In our example file there is the same picture on two subsequent slides. One gets saved as <draw:frame draw:style-name="gr9" draw:text-style-name="P1" draw:layer="layout" svg:width="16cm" svg:height="10.667cm" svg:x="6.6cm" svg:y="8cm"> <draw:image xlink:href="Pictures/10000201000004B300000322CD561078D6D62065.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"> <text:p/> </draw:image> </draw:frame> and on the next slide it's <draw:frame draw:style-name="gr9" draw:text-style-name="P1" draw:layer="layout" svg:width="16cm" svg:height="10.667cm" svg:x="6.6cm" svg:y="8cm"> <draw:image xlink:href=""> <text:p/> </draw:image> </draw:frame> I will try to trim down the presentation to a minimal example and attach it later Note: this is just an example, there are other places where an image is not repeated and still missing while other unrelated images remain. I had the same issue in 2014 on my master thesis presentation, no fun! was running the version of Impress that was current on Fedora at that time. Now I'm on Ubuntu 16.04 with the version number given above
Thank you for reporting the bug. it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
I checked back with my coworker who encountered the bug and he actually runs 5.4.4.2 from LP-PPA-LibreOffice/Now deb http://ppa.launchpad.net/libreoffice/ppa/ubuntu xenial main
Why did you change the version tag? I updated it to the version my coworker was using when the bug occurred ( 5.4.4.2 as stated in #2). I put in 5.1.6.2 solely because that is the version I use and which is distributed by Ubuntu 16.04. However I didn't know he had installed a newer version from PPA (as stated in #2) Just read now that this field means earliest affected not latest reproduced, so then it should probably be 4.1. (the version used in fedora core 19 during my master thesis)
Yep, would be cool to get a minimal test case.
Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
We are running into the same problem using Draw (also using Linux), where images are "randomly" lost, but no particular pattern or rationale is observed. Similar to OP, there are a lot of duplicate pictures in these large (30+ page) documents. So unfortunately no unit test or "steps to reproduce" are available - but it happens VERY frequently (using LO 5.4 and now 6.0.6). I tested a few different scenarios. 1.) insert an image into page1 and copy the entire page 4 times. Pictures folder contains a single picture. Deleting a page (tried first, last, middle) and reloading was fine. 2.) create a 4 page document, insert an image into page1, copy the image, and paste it into the remaining three pages. Pictures folder contains a single picture. Deleting a picture from one of the pages, and reloading was fine. 3.) create a 4 page document, and insert an the same image into each page separately using insert image (not copy paste). Pictures folder contains a single picture (that was unexpected!!). 4.) unzipped the file, deleted the picture from the pictures folder, and re-zipped into .odg. File opened without complaint, but images were lost. Upon saving, xlink:href="" exactly as indicated by OP. Observations and conclusions: A.) in our 30+ page document, some of the images are duplicated multiple times in the Pictures folder (at least 5 times in one case, under different ID names of course). So this is slightly inconsistent - I couldn't duplicate this because changing the filename or the file path of the to-be-imported file still resulted in a single picture instance. B.) likely the image itself is irrelevant since sometimes one disappears and at a different time another will disappear. C.) I expect that the root problem is that the image in the Pictures file is removed when still referenced elsewhere, either through corruption, or through document cleanup. The key will be to find a reproducable way to trigger this.
Justin: if it happens very frequently, is there a chance you could test with master? Hopefully this work will have fixed the problem: https://tomazvajngerl.blogspot.com/2018/01/improving-image-handling-in-libreoffice.html
I should note that crashing may be related to this - which would make a lot of sense as a cause of missing pictures - however the last communication from her makes it sound as if no crashes had occurred but the problem was still seen when "I made some changes in one doc, reducing the number of pages, which caused some icons to vanish". Unfortunately, as I mentioned earlier, we can't recreate this on-demand yet.
attachment 144412 [details] from bug 119479 is one of the documents I was using to do my testing in comment 6. It doesn't really qualify for the NEEDINFO request though since the procedure to lose the images is unknown still.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20190321
Dear Simon Schmeisser, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp