Bug 117860 - FORMATTING rotated images by manipulating the resize handles is inconsistent and unpredictable
Summary: FORMATTING rotated images by manipulating the resize handles is inconsistent ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.0.beta1+
Hardware: x86-64 (AMD64) All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: implementationError
Depends on:
Blocks: Object-Rotation
  Show dependency treegraph
 
Reported: 2018-05-28 18:09 UTC by Christoffer
Modified: 2022-12-22 22:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Rotation crops the picture. Further resizing is unpredictable (1.55 MB, application/x-matroska)
2019-01-25 03:49 UTC, DarkTrick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoffer 2018-05-28 18:09:16 UTC
Description:
Issues with transforming an image's horizontal/vertical size and aspect ratios if they are rotated by LibreOffice. Only Writer appears affected.
Using the resize handles on the image's edges will modify the size and aspect ratio in an unpredictable and inconsistent way.

Steps to Reproduce:
1. Rotate an image e.g. 45 degrees and attempt to change the size by manipulating the edge points.
2. For example shrink the image horizontally by 50% twice consecutively.
3. Then extend it to 100% again.

Actual Results:  
(1) The aspect ratio doesn't change accordingly and it's difficult to predict how it will change.
(2) The vertical size was shrunk even though I didn't change it.

Expected Results:
The aspect ratio and size of the image is the same as before the resize.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Version: 6.1.0.0.beta1 (x64)
Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
Locale: sv-SE (sv_SE); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Comment 1 Stéphane Guillou (stragu) 2018-05-29 03:19:05 UTC
It is true that the current situation is unintuitive as:

1. The rotation creates a new bounding box so it contains the rotated picture and still has horizontal and vertical sides;
2. Resizing then gives a "preview" (dotted line highlighted in blue) that does not match the end result (but would match the bounding box of the non-rotated image).

However, the behaviour where moving the "non-corner" handles does not conserve the aspect ratio is expected. Only the corner handles do conserve the aspect ratio.

Tested on:

Version: 6.1.0.0.beta1
Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0
CPU threads: 2; OS: Linux 3.13; UI render: default; VCL: kde4; 
Locale: en-GB (en_GB.UTF-8); Calc: group
Comment 2 Buovjaga 2018-06-20 18:15:39 UTC
Yep.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 0929a98acca8ec4d86caa97d3090a39f89f35f90
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on June 20th 2018
Comment 3 DarkTrick 2019-01-25 03:49:26 UTC
Created attachment 148614 [details]
Rotation crops the picture. Further resizing is unpredictable

I have a similar problem on 6.0.7.3.
I attached a video from my experience: Rotating will crop the picture in a way, that is not 'fixable'. 
As this behaviour renders the "image rotation" feature completely useless, I would set the priority to higher than "minor". 

If you consider my experience as a new "report"/bug/suggestion, please let me know.
Comment 4 QA Administrators 2021-01-25 04:17:07 UTC Comment hidden (obsolete)
Comment 5 DarkTrick 2021-02-01 13:27:10 UTC
Version: 7.0.3.1
Build ID: 00(Build:1)
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.0.3-0ubuntu0.20.10.1
Calc: threaded

- Not present with unrotated images.
- Still present with rotated images.