Bug 153919 - Shift+resize aspect ratio not maintained for images
Summary: Shift+resize aspect ratio not maintained for images
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Image-Caching
  Show dependency treegraph
Reported: 2023-03-02 09:03 UTC by Eyal Rozenberg
Modified: 2023-03-29 15:38 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2023-03-02 09:03:47 UTC
If I insert an image into an Impress or Draw document, and shift-resize it - the aspect ratio is not maintained.

(It is maintained for other objects like text boxes and various shapes.)

Seen with:

Version: / LibreOffice Community
Build ID: 40(Build:1)
CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US
Debian package version: 4:7.4.5-2
Comment 1 raal 2023-03-02 17:27:51 UTC
confirm in Version: (X86_64) / LibreOffice Community
Build ID: 4e6ab75c1a907398d24768d19cf097a4892d374c
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: x11
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

works in Version (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 2 raal 2023-03-02 17:52:14 UTC
This seems to have begun at the below commit.
Adding Cc: to Samuel Mehrbrodt ; Could you possibly take a look at this one?
 52848ed173a6efb9a1931fe7e3441057eb653684 is the first bad commit
commit 52848ed173a6efb9a1931fe7e3441057eb653684
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sun Mar 15 03:10:12 2015 +0800

    commit ef58e10844dff60cd218306b059ec81d8421f961
    Author:     Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
    AuthorDate: Fri Sep 26 18:45:42 2014 +0200
    Commit:     Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
    CommitDate: Fri Sep 26 18:46:15 2014 +0200
        fdo#83808 Scale images proportionally by default in Impress/Draw
Comment 3 raal 2023-03-02 17:56:11 UTC
ok, se bug tdf#83808 - logic was changed.
Comment 4 Eyal Rozenberg 2023-03-02 19:03:09 UTC
This logic change is a _bug_

It is:

1. Inconsistent with the resizing of other objects.

2. Inconsistent with other (non-Office) applications 

3. IIANM, inconsistent with MS Office

Please revert this ASAP.

If people want image scaling to be proportional by default - link it to some toggle in the Size and Position dialog (e.g. constrain proportions - that already exists). But you can't just have shift + resize do the _opposite_ of what it does everywhere.
Comment 5 Heiko Tietze 2023-03-03 08:04:25 UTC
It was an intentional decision by the design team for bug 71669 - Scale images proportionally by default. The point is that we support the shift modifier but consider the default to be proportional in case of images and to be variable otherwise. So you have to press shift for shapes to get it scaled but not for images.
Comment 6 Eyal Rozenberg 2023-03-03 21:04:38 UTC
(In reply to Heiko Tietze from comment #5)

1. Scaling proportionally by default does not require scaling non-proportionately when using Shift+mouse drag, and certainly not scaling non-proportionately _by default_ when using Shift+mouse drag.

2. I understand this happened by explicit decision. The decision was, IMNSHO, a mistake, and I gave the reasons above.

What is the justification for the chosen behavior? It seems to me - reading the linked bug - that the idea was to switch the behaviors between shift and no-shift, and thus supposedly minimize changes, or not reduce the "availability" of non-proportionaly resizing. Am I mistaken? Were alternatives (other than the previous state of affairs) presented, considered and rejected?
Comment 7 Heiko Tietze 2023-03-06 07:40:17 UTC
(In reply to Eyal Rozenberg from comment #6)
> Were alternatives (other than the previous state of affairs) presented,
> considered and rejected?

Wasn't involved myself but maybe Cor has insights. 

My take in general: do not touch existing functionality without a clear issue, use case, scenario.
Comment 8 Stéphane Guillou (stragu) 2023-03-16 14:25:51 UTC
In my opinion, constant aspect ratio needs to remain the default for images. Other objects are usually vector objects (e.g. shapes) or containers (e.g. text boxes) that don't have the same issues as bitmaps we usually don't want to see stretched or squished.

Images can still be resized without preserving the aspect ratio by using the middle handles instead.

For a comparison and some ideas:

- GIMP preserves the aspect ratio for _all_ handles by default, and uses Shift to make it unrestricted.
- Google Docs does the same as LO for images (but no Shift override). However, seems to be consistent for other objects (e.g. charts).
- MS Office does the same as LO (need to go into Size options to unlock aspect ratio, which also makes Shift override available). Other objects are unrestricted by default, with Shift override to keep ratio (I tested shapes and charts).
Comment 9 Eyal Rozenberg 2023-03-16 22:09:35 UTC
(In reply to Stéphane Guillou (stragu) from comment #8)

With respect - I believe you've misunderstood what's being asked for in this bug. 

I will address a couple of your comparisons though:

> - GIMP preserves the aspect ratio for _all_ handles by default, and uses
> Shift to make it unrestricted.

So, GIMP is entirely consistent. We are not consistent w.r.t. the default resizing, but - let us at least be consistent w.r.t. shift-resize behavior.

> - Google Docs does the same as LO for images (but no Shift override).

So, Google Docs does by default what I suggest we also do by default: Shift+resize maintains aspect ratio.
Comment 10 Stéphane Guillou (stragu) 2023-03-29 15:38:52 UTC
So a solution might be that commit 52848ed173a6efb9a1931fe7e3441057eb653684 is reverted and that instead we turn "keep aspect ratio" on by default when inserting an image, as suggested in bug 125239 (making sure that the setting is indeed respected when using the handles, and not just used for the in-dialog numerical values – see for example that it is not for shapes in bug 84385).