After inserting images as "linked" (as a workaround tentative to bug #46447) and editing a bit the presentation, some images are no more displayed as they are looked for in the wrong path. For example, content.xml before the issue: <draw:image xlink:href="../images/2011-10-WallStreetJournal_AA_SW.PNG" [...] Then: <draw:image xlink:href="../images/2011-10-WallStreetJournal_AA_SW.PNG%3FrequestedName=2011-10-WallStreetJournal_AA_SW" [...] This happened both with PNG and SVG images. I could not determine what precise action triggers the issue. The bug could be related to #46447 where embedded images href becomes blank and the picture disappears from Pictures folder.
thanks for reporting, I can't confirm but trust you! Cor
I can confirm this bug with following test conditions: - AutoRecovery (auto save) activated every 1 minute - with a PNG file *) But I guess this also happen with any auto-save intervals and any image file Step to reproduce: 1. Create new presentation 2. Insert > Image > From File 3. Select an image file and tick "Insert as Link" in the bottom left > Open > Keep Link 4. Wait for at least 1 minute to let auto-save executed 5. Save as an ODP 6. Close & reopen the ODP file Reproduced with LO 4.3.0.3, 4.3.0.1, 4.2.6.1, 4.2.5.2 - Ubuntu 12.04 x86 Not reproduced with LO 4.3.0.0.beta1, 4.2.4.2 Upping the Importance since AFAIK this is a quite common function and dataloss
Problem not reproduced if file saved before auto save executed as observed in: https://bugs.freedesktop.org/show_bug.cgi?id=81423#c1
*** Bug 81423 has been marked as a duplicate of this bug. ***
Looks like no problem with SVG image
To get rid of any interference, I installed Debian 7 in a virtual machine, with only the main libreoffice archive (LibreOffice_4.2.5_Linux_x86_deb.tar.gz) With default settings, I did : 1. Lauch Libreffice 2. Create a new presentation 2. Save the odp file by "save as ..." 3. Insert a picture "as a link" and, yes, keep the link. 4. Save the file. 5. Check content.xml and link 6. Move the picture a bit. 7. Save the odp file. 8. Check content.xml and link No need to wait for automatic saving. Now the results : The bug appears at step 7. * With a png file, the string beginning with "%3FrequestedName=" is added to the link, broking it. * With a svg file, the bug is PRESENT, but different : in that case the linked svg file is incorporated in the Pictures directory in the odp file, as it would have been manually incorporated ... So the bug is hidden (but behavior is wrong).
(In reply to comment #6) > 6. Move the picture a bit. Emh..looks more complex now. That action is subjective. I'll do testing again
Ok I got it Marc. Nice steps.. :) Tried again with reproducing steps in comment 6 - with x86 deb packages without desktop integration - default profile (15 minutes autosave enabled by default) Did those steps in comment 6 from step 3 - 8 (only 2x saving, after image inserted & after image moved) With PNG files (tried several different PNG files from different locations) -> Reproduced in 4.3.0.3, 4.2.6.1 -> Not reproduced in 4.2.4.2, 4.3.0.0.beta1 Seems we have 2 similar cases here with different triggers: - Comment 2 -> execution of autosave, NO modification of image (in this case: image moved) - Comment 6 -> NO execution of autosave, manual file saving required before image moved (after image inserted) *) Both 2 cases confirmed regression against LO 4.2.4.2 and 4.3.0.0.beta1 Perhaps we need separate bug report for SVG images since it's different behavior from Marc observation.
(In reply to comment #6) > * With a png file, the string beginning with "%3FrequestedName=" is added to > the link, broking it. > * With a svg file, the bug is PRESENT, but different : in that case the > linked svg file is incorporated in the Pictures directory in the odp file, > as it would have been manually incorporated ... So the bug is hidden (but > behavior is wrong). Confirm that. If we do SVG insertion (as link), there is a tag like this in content.xml: <draw:image xlink:href="Pictures/10000201000000F6000000F65107668F.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> Looks like the SVG image embeded as a PNG. So the image still shown in the ODP even actual SVG link is broken with additional "%3FrequestedName=" in the link. But if we do PNG insertion as link, that tag not exist.
(In reply to comment #9) > (In reply to comment #6) > > * With a png file, the string beginning with "%3FrequestedName=" is added to > > the link, broking it. > > * With a svg file, the bug is PRESENT, but different : in that case the > > linked svg file is incorporated in the Pictures directory in the odp file, > > as it would have been manually incorporated ... So the bug is hidden (but > > behavior is wrong). > > Confirm that. If we do SVG insertion (as link), there is a tag like this in > content.xml: > > <draw:image xlink:href="Pictures/10000201000000F6000000F65107668F.png" > xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> > > Looks like the SVG image embeded as a PNG. Yes, during the first saving, a png copy of the linked svg is made and included in the odp file. > So the image still shown in the > ODP even actual SVG link is broken with additional "%3FrequestedName=" in > the link. Yes. > But if we do PNG insertion as link, that tag not exist. Yes, that is what happens. And no copy is put in the odp file for a source png file.
> Seems we have 2 similar cases here with different triggers: > - Comment 2 -> execution of autosave, NO modification of image (in this > case: image moved) > - Comment 6 -> NO execution of autosave, manual file saving required before > image moved (after image inserted) > *) Both 2 cases confirmed regression against LO 4.2.4.2 and 4.3.0.0.beta1 Maybe this is enventually the same case. I did another experiment. In the options, Libreoffice > General > Document Status, I ticked "Allow to save document even the document is not modified". Afer linking the picture, this allowed me to save twice, without moving the picture between the two saving steps. The bug appeared at the second saving. If we sum up, in all cases what is happening is : 1. We link a picture in the document 2. We make a first saving, in which the link is correct 3. We make a seconde saving, which breaks links with this %3FrequestedName=...
I believe this has been fixed by commit fd641c7b23ce4205c29fc0c564b73336cb2cfb07. Could someone check with the latest daily build?
(In reply to comment #12) Unfortunately I still can't test since I haven't seen x86 deb package newer than 2014-07-22 in http://dev-builds.libreoffice.org/daily
(In reply to comment #12) > I believe this has been fixed by commit > fd641c7b23ce4205c29fc0c564b73336cb2cfb07. Could someone check with the > latest daily build? Seems FIXED with that commit. Tried PNG and SVG insertion as link in Ubuntu 12.04 x86 with steps in comment 2 and comment 6, works correctly with: Version: 4.3.1.0.0+ Build ID: ce65a47f6028879337e9e133053cc397b1b582bd TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:libreoffice-4-3, Time: 2014-07-30_10:54:10 Not yet tried 4.2.7.0.0+
Tested with nighty build (libreoffice-4-2~2014-07-30_13.16.10_LibreOfficeDev_4.2.7.0.0_Linux_x86_deb.tar.gz) THe bug is gone. However, with rc2 4.2.6 (LibreOffice_4.2.6.2_Linux_x86_deb.tar.gz)the bug is still present. I doubt it would be a good idea to release 4.2.6 with that bug ...
*** Bug 84630 has been marked as a duplicate of this bug. ***
I'm still affected by this bug on LibreOffice 4.4.3.2 What I'm trying to do is adding a picture in the header (not body). After I close the document and reopen it, it's gone. It doesn't work neither linked nor embedded, i tried jpg and png formats.
(In reply to TeslaZap from comment #17) > I'm still affected by this bug on LibreOffice 4.4.3.2 > > What I'm trying to do is adding a picture in the header (not body). After I > close the document and reopen it, it's gone. > > It doesn't work neither linked nor embedded, i tried jpg and png formats. Completely different issue and code base. Open a new bug with complete steps to reproduce.
(In reply to V Stuart Foote from comment #18) > (In reply to TeslaZap from comment #17) > > I'm still affected by this bug on LibreOffice 4.4.3.2 > > > > What I'm trying to do is adding a picture in the header (not body). After I > > close the document and reopen it, it's gone. > > > > It doesn't work neither linked nor embedded, i tried jpg and png formats. > > Completely different issue and code base. Open a new bug with complete steps > to reproduce. Actually, your issue would seem to be that of TDF bug 89245 -- FORMATTING, FILESAVE: Header and footer background images are not saved
Migrating Whiteboard tags to Keywords: (BibisectRequest) [NinjaEdit]