As a computer graphics guy, when I do some presentation I often show some image processing pipelines. So I export the intermediate results of my application, put the first image into a slide, crop to an interesting part of the image. Then I duplicate the slide a few times, replace the image with the next exports from the pipeline, and that's it, super easy. The images in the slides align perfectly, it just works. In 5.2, replacing a cropped image places the full new image into the cropped region. That means I have to apply the positioning and cropping settings of the first image to all the others manually, which for me boiled down to making a screenshot of the positioning and cropping dialogs of the first image, and then manually put the numbers into these dialogs for the second image. So, long story short, in 5.2 there doesn't seem to be a reasonable easy way to create multiple cropped and aligned images.
UX needs to decide what the experience should be like. To say the least, this is a very minor issue. Punting to UX.
Hi Johnanes, Are you saying that this worked the way you wanted it to work in previous versions and now in 5.2 it works differently?
Yes. However, i have noticed afterwards that the image replacement worked in 5.1 only if the pixel dimensions of original and replacement were equal. If not, i actually have no idea what should happen, but it went all distorted and really unexpected if i remember correctly. So, iirc, there was one special case in 5.1 that worked as i would like it to work (replacing image with one of equal dimensions), everything else in 5.1 and everything in 5.2 seemed buggy to me, as in not only unhelpful, but actually buggy.
Hi Johnanes, Yes i can confirm that the functionality has been broken in 5.2 and master, but works correctly in 5.1. Version: 5.2.3.0.0+ Build ID: a3218c2737fb3d78989e470991b1c712fc3a4275 CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-2, Time: 2016-09-23_09:38:39 Locale: en-US (en_US.UTF-8); Calc: group Version: 5.3.0.0.alpha0+ Build ID: e64ea98801d20e5024da900a0ac8faaf565f4bf3 CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-10-18_04:29:35 Locale: en-US (en_US.UTF-8); Calc: group @QA: Importance should likely be changed as this is a regression.
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 f8cb956726286d20f1a72dbffa86c19241b4aa02 is the first bad commit commit f8cb956726286d20f1a72dbffa86c19241b4aa02 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Jul 9 07:48:41 2016 -0700 source fd6655080e181de4b78e31f13fe8ba35de8edfe5 git bisect log # bad: [7e014b5a90bc38fc7c4a6fdcc308679c61f9fbc3] source 73c7e0921d752df53004ed55735f3e8888cc592f # good: [defb73f1c6e2a66dbd21ba89e684f57427e8bc4b] source 5b168b3fa568e48e795234dc5fa454bf24c9805e git bisect start 'origin/master' 'oldest' # bad: [af17669bd4a6c2af0d7d93ada6f219756a8bcd9b] source 2263ff8550a896312d2eae16e0b1b2e9b0d6c884 git bisect bad af17669bd4a6c2af0d7d93ada6f219756a8bcd9b # good: [0f3f3f1609925a0c66765475448aeeff61c2ffef] source 725815366eb5543b4465af60a1072f1738db9147 git bisect good 0f3f3f1609925a0c66765475448aeeff61c2ffef # bad: [a388c2d11c62934417cb7dcaaa0746ae798290e2] source 2ed35ad17e4f5dd8a329681a92b896fd14850465 git bisect bad a388c2d11c62934417cb7dcaaa0746ae798290e2 # good: [1b913f3f59963fdcb2f10d2e1503dab6da18d200] source 97fda453bc43fbae3d0a9fd05259e92d3205fd06 git bisect good 1b913f3f59963fdcb2f10d2e1503dab6da18d200 # good: [4d58dd03af008d1f7298056a8d20760625192d05] source 20b9cbd0e586fe89f8e1bdd942135445a256af7b git bisect good 4d58dd03af008d1f7298056a8d20760625192d05 # bad: [46c1fac940d132cb1b8beb83c40e5d319e5caa0f] source 0f92d79708118d99fca4c60c30cd5c63c24e02fb git bisect bad 46c1fac940d132cb1b8beb83c40e5d319e5caa0f # good: [d7d13fca18cc1c18628c873949ebabc615026ee0] source 64354e6479e750e4a126abfae5d3f32a1110315e git bisect good d7d13fca18cc1c18628c873949ebabc615026ee0 # good: [d87aea8550383ffc15771d5e05e69f9bdc70fa07] source 9fee132c18b658c9ea9fb1114c1fefa56b57532a git bisect good d87aea8550383ffc15771d5e05e69f9bdc70fa07 # bad: [f7c905c653bce0404d254a4d1472652f7f35a4ab] source f3ca52306a604d6702cd31d58c5c1902340090ab git bisect bad f7c905c653bce0404d254a4d1472652f7f35a4ab # bad: [bdcc6617fe8e4dfc23feeaa1ec5147a78f538dad] source 6f0e3d508dea229e456e3b29abe2f2b3c77a2cf9 git bisect bad bdcc6617fe8e4dfc23feeaa1ec5147a78f538dad # bad: [f8cb956726286d20f1a72dbffa86c19241b4aa02] source fd6655080e181de4b78e31f13fe8ba35de8edfe5 git bisect bad f8cb956726286d20f1a72dbffa86c19241b4aa02 # good: [898e17423a4c0396e7526a8e5d40116350fabe37] source 28a03248b1d1649e157b788e43dfe8326f165379 git bisect good 898e17423a4c0396e7526a8e5d40116350fabe37 # first bad commit: [f8cb956726286d20f1a72dbffa86c19241b4aa02] source fd6655080e181de4b78e31f13fe8ba35de8edfe5
I guess this can be closed as RESOLVED DUPLICATED of bug 103662 as both were introduced by the same commit *** This bug has been marked as a duplicate of bug 103662 ***
See https://bugs.documentfoundation.org/show_bug.cgi?id=103662#c8 for a solution for this.
i'm not sure in how far the fill type bitmap thing is a solution here. if i set the fill type on an image, nothing happens, because the fill type is just the background behind the opaque image. even if i make the image transparent, there is no way to change the cropping area or just about anything else on the background image. i'm not even sure the other bug is all that similar to this one here...? let me re-phrase my use case: i want to insert an image, crop to an interesting area, and then on a duplicated slide, replace the image with the next one (of equal dimensions) while keeping the cropped area. this is, as far as i can tell, impossible in 5.2 and 5.3. samuel, could you confirm you actually want to keep the current behavior? do you have a workaround?
*** Bug 107449 has been marked as a duplicate of this bug. ***