confirm in Version: 7.6.0.0.alpha0+ (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 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

This seems to have begun at the below commit.
Adding Cc: to Samuel Mehrbrodt ; Could you possibly take a look at this one?
Thanks
 52848ed173a6efb9a1931fe7e3441057eb653684 is the first bad commit
commit 52848ed173a6efb9a1931fe7e3441057eb653684
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sun Mar 15 03:10:12 2015 +0800

    source-hash-ef58e10844dff60cd218306b059ec81d8421f961
    
    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

ok, se bug tdf#83808 - logic was changed.

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.

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.

(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?

(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.

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).

(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.

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).

(In reply to Stéphane Guillou (stragu) from comment #10)
> So a solution might be that commit 52848ed173a6efb9a1931fe7e3441057eb653684
> is reverted

The link is dead

> and that instead we turn "keep aspect ratio" on by default when
> inserting an image, as suggested in bug 125239

It would make things less-bad, but won't resolve this.

When I resize a shape, the aspect ration is not (generally) maintained; when I Shift+resize it - the aspect ratio is maintained. Images should behave the same, period. Consistency and flexibility.


PS - Inkscape resizes with no aspect ration maintenance usually, and locks the aspect ration with Ctrl+Resize. (Not sure what Shift-resize does).

(In reply to Eyal Rozenberg from comment #11)
> The link is dead
Sorry, that's the bibisect build commit. Actual commit should be ef58e10844dff60cd218306b059ec81d8421f961.

(In reply to Heiko Tietze from comment #5)
> It was an intentional decision by the design team for bug 71669...
(In reply to Heiko Tietze from comment #7)
> do not touch existing functionality without a clear issue