Bug 103031 - Replacing an image does not keep cropping settings in 5.2
Summary: Replacing an image does not keep cropping settings in 5.2
Status: RESOLVED DUPLICATE of bug 103662
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.2.2.2 release
Hardware: All All
: lowest minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2016-10-06 08:29 UTC by Johannes
Modified: 2017-04-29 17:03 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes 2016-10-06 08:29:39 UTC
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.
Comment 1 Joel Madero 2016-10-08 05:00:03 UTC
UX needs to decide what the experience should be like. To say the least, this is a very minor issue. Punting to UX.
Comment 2 Yousuf Philips (jay) (retired) 2016-10-08 10:08:31 UTC
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?
Comment 3 Johannes 2016-10-22 10:35:28 UTC
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.
Comment 4 Yousuf Philips (jay) (retired) 2016-10-22 11:22:02 UTC
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.
Comment 5 raal 2016-10-23 07:06:42 UTC
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 sha:fd6655080e181de4b78e31f13fe8ba35de8edfe5

git bisect log
# bad: [7e014b5a90bc38fc7c4a6fdcc308679c61f9fbc3] source sha:73c7e0921d752df53004ed55735f3e8888cc592f
# good: [defb73f1c6e2a66dbd21ba89e684f57427e8bc4b] source sha:5b168b3fa568e48e795234dc5fa454bf24c9805e
git bisect start 'origin/master' 'oldest'
# bad: [af17669bd4a6c2af0d7d93ada6f219756a8bcd9b] source sha:2263ff8550a896312d2eae16e0b1b2e9b0d6c884
git bisect bad af17669bd4a6c2af0d7d93ada6f219756a8bcd9b
# good: [0f3f3f1609925a0c66765475448aeeff61c2ffef] source sha:725815366eb5543b4465af60a1072f1738db9147
git bisect good 0f3f3f1609925a0c66765475448aeeff61c2ffef
# bad: [a388c2d11c62934417cb7dcaaa0746ae798290e2] source sha:2ed35ad17e4f5dd8a329681a92b896fd14850465
git bisect bad a388c2d11c62934417cb7dcaaa0746ae798290e2
# good: [1b913f3f59963fdcb2f10d2e1503dab6da18d200] source sha:97fda453bc43fbae3d0a9fd05259e92d3205fd06
git bisect good 1b913f3f59963fdcb2f10d2e1503dab6da18d200
# good: [4d58dd03af008d1f7298056a8d20760625192d05] source sha:20b9cbd0e586fe89f8e1bdd942135445a256af7b
git bisect good 4d58dd03af008d1f7298056a8d20760625192d05
# bad: [46c1fac940d132cb1b8beb83c40e5d319e5caa0f] source sha:0f92d79708118d99fca4c60c30cd5c63c24e02fb
git bisect bad 46c1fac940d132cb1b8beb83c40e5d319e5caa0f
# good: [d7d13fca18cc1c18628c873949ebabc615026ee0] source sha:64354e6479e750e4a126abfae5d3f32a1110315e
git bisect good d7d13fca18cc1c18628c873949ebabc615026ee0
# good: [d87aea8550383ffc15771d5e05e69f9bdc70fa07] source sha:9fee132c18b658c9ea9fb1114c1fefa56b57532a
git bisect good d87aea8550383ffc15771d5e05e69f9bdc70fa07
# bad: [f7c905c653bce0404d254a4d1472652f7f35a4ab] source sha:f3ca52306a604d6702cd31d58c5c1902340090ab
git bisect bad f7c905c653bce0404d254a4d1472652f7f35a4ab
# bad: [bdcc6617fe8e4dfc23feeaa1ec5147a78f538dad] source sha:6f0e3d508dea229e456e3b29abe2f2b3c77a2cf9
git bisect bad bdcc6617fe8e4dfc23feeaa1ec5147a78f538dad
# bad: [f8cb956726286d20f1a72dbffa86c19241b4aa02] source sha:fd6655080e181de4b78e31f13fe8ba35de8edfe5
git bisect bad f8cb956726286d20f1a72dbffa86c19241b4aa02
# good: [898e17423a4c0396e7526a8e5d40116350fabe37] source sha:28a03248b1d1649e157b788e43dfe8326f165379
git bisect good 898e17423a4c0396e7526a8e5d40116350fabe37
# first bad commit: [f8cb956726286d20f1a72dbffa86c19241b4aa02] source sha:fd6655080e181de4b78e31f13fe8ba35de8edfe5
Comment 6 Xisco Faulí 2016-11-27 15:19:18 UTC
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 ***
Comment 7 Samuel Mehrbrodt (CIB) 2016-12-13 14:33:12 UTC
See https://bugs.documentfoundation.org/show_bug.cgi?id=103662#c8 for a solution for this.
Comment 8 Johannes 2016-12-29 17:55:27 UTC
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?
Comment 9 Buovjaga 2017-04-29 17:03:55 UTC
*** Bug 107449 has been marked as a duplicate of this bug. ***