Bug 86329 - EDITING: Image crop shouldnt be set to proportionate in Impress/Draw
Summary: EDITING: Image crop shouldnt be set to proportionate in Impress/Draw
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.0.0 target:4.4.4
Keywords: bibisectRequest, regression
: 89758 (view as bug list)
Depends on:
Blocks: Impress-Images Draw-Images
  Show dependency treegraph
 
Reported: 2014-11-16 03:24 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-06-18 21:04 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot showing the previous dialog to crop images (76.68 KB, image/png)
2015-02-17 11:30 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-11-16 03:24:11 UTC
Now the image scaling was introduced into all other modules in bug 83808, i believe this setting also effects the image crop tool in impress and draw, as it crops proportionately unless you press shift.

Version: 4.4.0.0.alpha2+
Build ID: 19ad91f7bc7ca96c55e0ca3450608f616f87c4ed
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-11-13_23:17:38
Comment 1 retired 2014-11-16 08:03:26 UTC
Jay, this WORKSFORME on Version: 4.4.0.0.alpha2+
Build ID: 30123b9559e2fb74c9db7d530c538a1c6dc7e32c
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2014-11-16_00:07:14

Setting to WORKSFORME. Can you double check with the latest nightly build if this persists for you? If so, please do re-open. I can recall, that writer and calc where the first to have the proportional image resizing and Impress indeed was forgotten. But in my test now it worked as expected.
Comment 2 Cor Nouws 2014-11-16 14:28:11 UTC
?? Me being confused by how I understand the report of Jay, and how I read the comment from foss ;)

So: the goal is that resizing works the same in all modules?
Comment 3 Yousuf Philips (jay) (retired) 2014-11-16 14:36:15 UTC
Hi foss,

I think you maybe misunderstanding the issue. The issue here is that crop shouldnt be scaled proportionately.

Version: 4.4.0.0.alpha2+
Build ID: 2f342c61616418c6ad7303d7f5efa27a28378681
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-16_00:33:40
Comment 4 Cor Nouws 2014-11-16 15:31:32 UTC
(In reply to Jay Philips from comment #3)

> I think you maybe misunderstanding the issue. The issue here is that crop
> shouldnt be scaled proportionately.

Ah, it's about cropping :)


CONFIRM: problem is that when you crop with the mouse, it does the same crop at all sided, unless you use Shift+mouse.
Comment 5 retired 2014-11-16 22:42:10 UTC
Misread title of this bug. Sorry for causing confusion. Yet i still believe proportional image resizing to be the best default. So i disagree with this being an issue.
Comment 6 retired 2014-11-16 22:49:38 UTC
Apologies. Wow I misread this bug for the 2nd time.

And yes, I do agree with Cor Nouws and Jay that proporional cropping isn't a good default.

Sorry guys!
Comment 7 Cor Nouws 2014-11-17 21:57:27 UTC
(In reply to foss from comment #6)

> Sorry guys!

No problem, you can always serve us apple pie ;)
Do you like that too, Jay :)
Comment 8 Yousuf Philips (jay) (retired) 2014-11-18 15:31:16 UTC
(In reply to Cor Nouws from comment #7)
> No problem, you can always serve us apple pie ;)
> Do you like that too, Jay :)

Yep i love me some apple pie. :D
Comment 9 tmacalp 2015-02-01 22:51:56 UTC
Oddly enough, when I tested this in 4.4.0.3 and current master, only the PREVIEW for a crop is proportional.  When you release the mouse button, the resulting crop is not constrained.  In fact, holding shift only changes the preview to be non-constrained and the resulting crop is still unconstrained.  So it is actually currently impossible to get a constrained crop.  

So, the following changes need to be made:
1. Fix the constrained behavior to make the preview while dragging consistent with what is actually set.
2. Reverse the shift-constrain behavior, so the default behavior for crop is to NOT be proportionally constrained.

Whatever the case, it looks like the new crop interface made it into the bibisect-44 repo.  The latest revision in the repo still has the old dialog, so I'll mark this as bibisectednewer.

It might be a little tricky to fix this one since, like everything else in LO, a lot of the code touches other behavior.  For instance, when adjusting image size was flipped to default to being constrained, it also made moving images constrained as well.  My guess is that a similar patch will need to be produced to specifically fix cropping too.
Comment 10 Yousuf Philips (jay) (retired) 2015-02-02 16:39:30 UTC
Thanks tmacalp for digging into it more as you are correct that the crop preview is different than the crop that appears when you release the mouse drag.

I had CCed samuel on this as he was the one who implemented the global proportionate changing of images in bug 83808.

Spoke to Qubit about bibisectNewer and he said it is dangerous to use, so i'm reading bibisectRequest and when it eventually gets bibisected, both can be removed.
Comment 11 Michael Weghorn 2015-02-07 01:47:40 UTC
Would it not - in general - be a good idea to use the Linux dbgutil Bibisect repo (that contains newer versions than the other Bibisect repositories, s. https://wiki.documentfoundation.org/QA/HowToBibisect#Testing_Versions) to bibisect bugs that cannot be bibisected with the "standard" Bibisect repos because the bugs are too new?

Or is this repository not reliable enough? (It is marked as "for testing purposes only.")
Comment 12 Yousuf Philips (jay) (retired) 2015-02-17 08:30:54 UTC
@Michael: Yes the latest bibisect repo should work till the current master.
Comment 13 Michael Weghorn 2015-02-17 11:28:57 UTC
bibisect result:

4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e is the first bad commit
commit 4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Thu Dec 18 05:59:20 2014 +0100

    2014-12-18: source-hash-e57b0ebeb7e75d36546f6abef3a26a8edc7dea7f

:100644 100644 f0bb717b2ff287197bfaa22233406e60044af9c0 aa66f24ad1e25f64ed7e798652e8b4594c126693 M	build-info.txt
:040000 040000 3c4cf305f1eadbe35f4fac38fff08f51721fef5f 7794c9f8660d711158b277d641aded43ded9a107 M	opt


$ git bisect log
# bad: [ad5ed3c0a2b049c70515c303e8150f5a75dd818f] 2015-02-06: source-hash-004304eb2fd1703d22dec0abf0170bb2ce493d0c
# good: [e4b0a61cedc6ac0e65a4a110fd83edd8295f4856] 2014-11-20: source-hash-d273a60bfdbf9bb7623bed38667ec0647753157c
git bisect start 'master' 'oldest'
# bad: [09b2fa5b1f166e0d6f077325f2ea5fec8c061b47] 2014-12-29: source-hash-4c9cf98819037fdb70cbe68f678f6498d5646736
git bisect bad 09b2fa5b1f166e0d6f077325f2ea5fec8c061b47
# good: [cc11b8ff286074f3edcc650b231c4ed3edaebc2f] 2014-12-09: source-hash-887cb59ac4bfca94f310baee3e9da58ccf9cb3e3
git bisect good cc11b8ff286074f3edcc650b231c4ed3edaebc2f
# bad: [74219a396267b26bfe81f8ea4b9142eb04bb0947] 2014-12-19: source-hash-b7e61384f135f9f513659bcfd2502a9d00acd2f9
git bisect bad 74219a396267b26bfe81f8ea4b9142eb04bb0947
# good: [e0c729d4968b1f602da2944a3324bea9921e4945] 2014-12-14: source-hash-f92183833fa569006602ac7e93c906d2094e0d4d
git bisect good e0c729d4968b1f602da2944a3324bea9921e4945
# good: [2f4a8813051de6bf388715f27cbf832dd3d9bb5b] 2014-12-16: source-hash-990dbcab759265de1497b15a93e53a5fe81ff48d
git bisect good 2f4a8813051de6bf388715f27cbf832dd3d9bb5b
# bad: [4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e] 2014-12-18: source-hash-e57b0ebeb7e75d36546f6abef3a26a8edc7dea7f
git bisect bad 4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e
# good: [4787587b8ee487f6eae6802b89ec40f991457f2c] 2014-12-17: source-hash-cccf45a3d3ea6b06e6c8a507645d23505a91e8d5
git bisect good 4787587b8ee487f6eae6802b89ec40f991457f2c
# first bad commit: [4435dc9e62f0b2a4bf0d738469c4e6ae0731e50e] 2014-12-18: source-hash-e57b0ebeb7e75d36546f6abef3a26a8edc7dea7f



Between those commits, the way of cropping images was changed.
* Before, a separate Dialog to crop the image was shown where you would specify for each side how much of the image should be cropped there.
* Afterwards (now), cropping works with handles at the sides of the image. The image crop tool preview is proportionately, while the result is not.
Comment 14 Michael Weghorn 2015-02-17 11:30:25 UTC
Created attachment 113448 [details]
screenshot showing the previous dialog to crop images

This screenshot shows the image crop dialog that was used previously.
Comment 15 Yousuf Philips (jay) (retired) 2015-02-17 13:47:51 UTC
Cropping an image with right-click crop was changed in bug 86627, but we are looking for crop behaviour differences within the UNO command (.uno:Crop).
Comment 16 tmacalp 2015-04-24 05:30:52 UTC
*** Bug 89758 has been marked as a duplicate of this bug. ***
Comment 17 tmacalp 2015-04-24 06:37:22 UTC
I've submitted a small patch to code review that should solve this particular issue:
https://gerrit.libreoffice.org/#/c/15505/

Unfortunately, I noticed many other issues with interactive cropping while testing this bug.  These may be reported elsewhere.

1. Hitting escape does not abort our crop, but applies it instead.

2. It's somehow possible to drag our crop area outside the bounds of the picture.  This will expand a clickable invisible area around our image.

3. There is no easy way to undo our cropping other than undo.  You would have to carefully drag your crop back to the edges of your picture.

4. There is no way to to constrain the resulting crop rectangle.  Even with this bug fixed, it now ACTS like holding shift will constrain proportions while you have your mouse button down, but the actual crop region is determined somewhere else.  Constrained crop really does need to be properly implemented.
Comment 18 Yousuf Philips (jay) (retired) 2015-04-24 17:41:11 UTC
(In reply to tmacalp from comment #17)
> I've submitted a small patch to code review that should solve this
> particular issue:
> https://gerrit.libreoffice.org/#/c/15505/

I've tested and pushed your commit and cherry picked it for 4.4.
https://gerrit.libreoffice.org/#/c/15521/

> 1. Hitting escape does not abort our crop, but applies it instead.

True.

> 2. It's somehow possible to drag our crop area outside the bounds of the
> picture.  This will expand a clickable invisible area around our image.

True.

> 3. There is no easy way to undo our cropping other than undo.  You would
> have to carefully drag your crop back to the edges of your picture.

Yes i've suggested we have an uncrop command. (bug 86628)

> 4. There is no way to to constrain the resulting crop rectangle.  Even with
> this bug fixed, it now ACTS like holding shift will constrain proportions
> while you have your mouse button down, but the actual crop region is
> determined somewhere else.  Constrained crop really does need to be properly
> implemented.

True.

Please do submit these bugs and CC me and i'll confirm them.
Comment 19 Yousuf Philips (jay) (retired) 2015-04-24 18:07:52 UTC
Seems Trent used the duplicate bug report number when submitting the patch. :D

--------------------------------

Trent MacAlpine committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=18a592a5bfc3c4592b7118cceae774fcc00ae94d

tdf#89758 Interactive crop preview shouldn't scale proportionally

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 20 Yousuf Philips (jay) (retired) 2015-04-25 19:52:32 UTC
Linking up the bug reports that Trent has just added and the uncrop bug.
Comment 21 Commit Notification 2015-04-30 08:33:37 UTC
Trent MacAlpine committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c60e9bb90e7954cbdebbf5db8e00ad6879c58f9&h=libreoffice-4-4

tdf#86329 Interactive crop preview shouldn't scale proportionally

It will be available in 4.4.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 22 Robinson Tryon (qubit) 2015-12-17 08:39:21 UTC Comment hidden (obsolete)