Not sure precisely which version introduced this, but it affects 5.2 and 5.3 nightly builds. 5.2.2.2 is definitely affected. Steps to reproduce: 1. Create new Draw document 2. Create a rectangle or similar object 3. Select the rectangle. 4. Go to Insert->Image (or Insert->Media->Image in 5.1) and select an image file. Expected result: The rectangle has the image file as its background. (in 3.x, 4.x, 5.0 and 5.1) Actual result: The image is inserted as a new object (5.2, 5.3 nightly) This is a massive problem for me as I'm using Draw to assemble webcomics. The only other way to set background images I know of is to add them to the clipart list (in the Area dialog). I have 6500 comic panels and three machines I edit the comic on, so I cannot really work that way. For now I have reverted to 5.1 . An annotated video showing the issue is available here: https://www.youtube.com/watch?v=sVGuKleM2u8 The issue first occurred after updating Ubuntu, which installed libreoffice 5.2. However it also occurs with the official DEB files from the site, with the 5.2.2.2 snap file, and I tested the nightly 5.3 build yesterday on Windows. At a guess, it broke around the time the menu option was moved from Insert->Media->Image to Insert->Image, but that could just be a coincidence.
Confirmed in Version: 5.3.0.0.alpha1+ Build ID: 1b0aa768f2c5da65074a6eacfed5f61a121fb13d CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; VCL: gtk3; Layout Engine: old; Locale: ca-ES (ca_ES.UTF-8); Calc: group but not in Version: 5.0.0.0.alpha1+ Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86 Locale: ca-ES (ca_ES.UTF-8)
It works in LO 5.1.6 and in Version: 5.2.0.2 Build ID: a7567a46e5d2953c320b13eb88a3981c4f9bd1e0 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: de-DE (de_DE) Workaround for Windows: Drag the image from the file manager to the shape while holding down Ctrl+Shift ("link" drop cursor).
"Workaround for Windows: Drag the image from the file manager to the shape while holding down Ctrl+Shift ("link" drop cursor)." The Ctrl+Shift drag workaround worked on Kubuntu using the Dolphin file manager under Linux, and the 5.2.2.2 snap package of LibreOffice. It does not work using the Thunar file manager in Xubuntu, instead causing LibreOffice to become unresponsive.
This seems to have begun at the below commit. Adding Cc: to Samuel Mehrbrodt ; Could you possibly take a look at this one? Thanks author Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2016-07-05 12:05:28 (GMT) committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2016-07-05 19:58:48 (GMT) commit fd6655080e181de4b78e31f13fe8ba35de8edfe5 (patch) tree b132314cd39e107b818f057cda33c07e6e9f2e47 parent 28a03248b1d1649e157b788e43dfe8326f165379 (diff) tdf#73742 Don't replace existing image when inserting one If we want to replace an image, we have an entry in the context menu for that. 553d0befedb3817328686d9244f50eb02c5707f5 is the first bad commit commit 553d0befedb3817328686d9244f50eb02c5707f5 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Sep 28 07:16:36 2016 +0200 source fd6655080e181de4b78e31f13fe8ba35de8edfe5 git bisect log # bad: [b356e15c1f14e3d0f0bb73662c878d14fc8aa992] source ada8a2123ea655142be74a11c23e042a0109d5f8 # good: [33e60eae04c889baf52713a73dc9944015408914] source 5b168b3fa568e48e795234dc5fa454bf24c9805e git bisect start 'origin/master' 'oldest' # bad: [78a4f08cf26d3f800710c509a99b1f4ad8a4e783] source db231633af4667e24281e0be69ab63ad3081fdc3 git bisect bad 78a4f08cf26d3f800710c509a99b1f4ad8a4e783 # good: [2a4fb8e296e2ebdd3259787a93bf3fddd59709fb] source b6b34d538398f8214daa5b160f764dc8b82ff9c5 git bisect good 2a4fb8e296e2ebdd3259787a93bf3fddd59709fb # bad: [f242c26f9a66345888c9dfcca843737a5dccb611] source 8ff6ba3da87a6ae8c36e8c9e44e66147c4dfb4e1 git bisect bad f242c26f9a66345888c9dfcca843737a5dccb611 # bad: [5d281e71b3fc26a009e3bd6445173dd54f96448c] source d2b2278aaba7f78afb1d8d3bf8fdb199f5a8cdbb git bisect bad 5d281e71b3fc26a009e3bd6445173dd54f96448c # bad: [3ae6c5c47f1c8daa839bc7ade01ce9cd66a1f225] source fdd1c64821a81d653ddc911e35149ff969e2f198 git bisect bad 3ae6c5c47f1c8daa839bc7ade01ce9cd66a1f225 # bad: [cd265e8cfcfb29a1804814c014ccd8557cf857f2] source dad4ddbbde689340d90f0480b838577dbbe618fe git bisect bad cd265e8cfcfb29a1804814c014ccd8557cf857f2 # bad: [36b4d6df4900693569a85d9c1741a09e18fa6227] source 68585e3045e07c1b8d269d3e8d428d7a38646dbb git bisect bad 36b4d6df4900693569a85d9c1741a09e18fa6227 # bad: [2bdf9b15b499177cd623882115b10237404030ee] source 50ba4a079ec6dbf00277bcfbbf15dc2f10d8cdcf git bisect bad 2bdf9b15b499177cd623882115b10237404030ee # good: [2f36184bf7605abef53c95fad8c10e3cba91c2b3] source a20b4e242bd0eee468352a7135975a57298c7a2f git bisect good 2f36184bf7605abef53c95fad8c10e3cba91c2b3 # bad: [553d0befedb3817328686d9244f50eb02c5707f5] source fd6655080e181de4b78e31f13fe8ba35de8edfe5 git bisect bad 553d0befedb3817328686d9244f50eb02c5707f5 # good: [0525837bf3a04c83b93d60543ea01c69807c98e3] source dd7a2c95b86d158be8d0637bdff13b9a0ed9954b git bisect good 0525837bf3a04c83b93d60543ea01c69807c98e3 # good: [304a7918e1f2f906846b982820c945a12516d793] source 9fee132c18b658c9ea9fb1114c1fefa56b57532a git bisect good 304a7918e1f2f906846b982820c945a12516d793 # good: [3d8b0e4867c4254e8e4c109b9ec72d96f1a4cc20] source 28a03248b1d1649e157b788e43dfe8326f165379 git bisect good 3d8b0e4867c4254e8e4c109b9ec72d96f1a4cc20 # first bad commit: [553d0befedb3817328686d9244f50eb02c5707f5] source fd6655080e181de4b78e31f13fe8ba35de8edfe5
Maybe there should be a more obvious way to set an image as background for objects?
(In reply to Samuel Mehrbrodt (CIB) from comment #5) > Maybe there should be a more obvious way to set an image as background for > objects? The first choice is to use area fill style > bitmap, either per dialog or via sidebar. I'm not sure what happens internally but the alt+drag trick works with Dolphin but not Krusader. It sets the area property to bitmap but doesn't add the image to .config/libreoffice/4/user/config/standard.sob. The drawback of this method is that you cannot change any setting like transparency later. In my opinion we should keep the current behavior and _insert_ images into the document instead of manipulating the area properties. But we also need an option to store the are fill style bitmap in the document only, guess this is the reason for the workflow. Simple solution is a checkbox in the open dialog and another in the context menu of the bitmaps list. It has to be clear if an image is in the document, perhaps per icon overlay. A completely different workflow is to insert the image and to use Edit Contour in Writer or ImageMap in Draw (the later is broken).
*** Bug 103031 has been marked as a duplicate of this bug. ***
In 5.3 in the Sidebar there is now an "Import" button when you choose "Bitmap" as fill type. Using that button does exactly what you want - it sets an external image as background for the rectangle. I verified that the image is included in the odg file. Everything inserted from the gallery is included, not linked. We made this change some years ago because on different OS the gallery is in different paths, so linking is very fragile. So I think this is resolved. If you have any improvements to the current workflow, please create a new bug and CC me - but I am against restoring the old behavior.
(In reply to Samuel Mehrbrodt (CIB) from comment #8) > In 5.3 in the Sidebar there is now an "Import" button when you choose > "Bitmap" as fill type. > Using that button does exactly what you want - it sets an external image as > background for the rectangle. > > I verified that the image is included in the odg file. Everything inserted > from the gallery is included, not linked. We made this change some years ago > because on different OS the gallery is in different paths, so linking is > very fragile. > > So I think this is resolved. If you have any improvements to the current > workflow, please create a new bug and CC me - but I am against restoring the > old behavior. Thanks, that solves the immediate problem, though I am worried about whether it will scale in future. Each time an image is imported it appears to be added to the gallery and persisted somewhere, even between documents. Is that a good idea? When people throw Word documents together at work, it's very rare for images to be reused later. The most common case for us is a one-off screenshot of something. Regarding the comic, assuming we keep to schedule with the comic, 12 months from now that gallery is going to have over 900 images in it. Will the list happily cope that or will there be performance problems? I guess that's something I can worry about when it happens, though.
(In reply to Joseph Morris from comment #9) > Each time an image is imported it appears to be added to the gallery and > persisted somewhere, even between documents. Is that a good idea? You can delete an image from the gallery at the new area fill style dialog using the context menu. But you are right that there is the need for temporarily add images.
*** Bug 107747 has been marked as a duplicate of this bug. ***
*** Bug 107449 has been marked as a duplicate of this bug. ***