Bug 143321 - Image height set to width when values in tab "Type" of Properties dialog are changed
Summary: Image height set to width when values in tab "Type" of Properties dialog are ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.0.0.beta1+
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2021-07-12 17:52 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2021-09-10 17:38 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document to show the problem (93.68 KB, application/vnd.oasis.opendocument.text)
2021-07-12 17:52 UTC, Stefan_Lange_KA@T-Online.de
Details
Bibisect log (3.04 KB, text/plain)
2021-07-12 20:26 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2021-07-12 17:52:22 UTC
Created attachment 173513 [details]
Test document to show the problem

The parameter "Height" of an image is set to the value of width when any value in the tab "Type" of the image properties dialog is changed.

Reproducing the problem:
- open the attached document "Test_Bildgröße_V2.odt"
- select the image and open the properties dialog
- go to tab "Type"
- change any value except "Height" or click into one of the listboxes (Position Horizontal, Vertical, ...)

What happens: the height value is set (7,50 cm) is changed to the width value (10,00 cm)

Expected: Height value remains unchanged. 

The problem also exists in LOdev 7.3.0.0 but not in LO 7.1 until recent build of LOdev 7.1.6.
Comment 1 m_a_riosv 2021-07-12 19:55:56 UTC
Confirmed,
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 0fc020fb73c86a20608e8dff12af607e60327379
CPU threads: 4; OS: Windows 10.0 Build 21390; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: threaded
Comment 2 Julien Nabet 2021-07-12 20:07:46 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this with gen rendering and with kf5 not with gtk3 rendering.
Comment 3 Julien Nabet 2021-07-12 20:20:38 UTC
Caolán: thought you might be interested in this one since it can't be reproduced with gtk3 but it can be reproduced with gen and kf5 renderings.

remark: gtk4 hasn't been available yet on Debian testing.
I suppose it's due to hard freeze of testing so I'll got to wait until Bullseyes version is released then gtk4 package should be available.
Comment 4 Telesto 2021-07-12 20:26:50 UTC
Created attachment 173518 [details]
Bibisect log

Bisected to
author	Miklos Vajna <vmiklos@collabora.com>	2021-06-07 18:03:33 +0200
committer	Miklos Vajna <vmiklos@collabora.com>	2021-06-07 18:49:07 +0200
commit 02c435082058ecf7f9d4d73cb47d31d0218dc10d (patch)
tree 4331d97262dc82150152d2cb93c68a2813bfcb53
parent a0bbeef0a8d9eeccc9ab9857851e0658139f2e1c (diff)
sw keep aspect ratio: add filter for this setting
SwViewOption::IsKeepRatio() was only in-memory, so ticking that checkbox
and restarting soffice disabled it again.

Handle this similar to e.g. the zoom factor which is mapped to a
view-specific settings.xml key.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=02c435082058ecf7f9d4d73cb47d31d0218dc10d
Comment 5 Telesto 2021-07-12 20:27:57 UTC
Adding CC to: Miklos Vajna
Comment 6 Miklos Vajna 2021-07-13 07:44:11 UTC
Your document explicitly enables KeepRatio in settings.xml:

          <config:config-item config:name="KeepRatio" config:type="boolean">true</config:config-item>

That is why master enables that checkbox for the image. 7.1 behaves differently because it ignores that setting. That being said this looks working as intended. If you disable that Keep Ratio checkbox once, it'll be also remembered in the document.

Does that help? Thanks.
Comment 7 Stefan_Lange_KA@T-Online.de 2021-07-13 09:54:12 UTC Comment hidden (obsolete)
Comment 8 Stefan_Lange_KA@T-Online.de 2021-07-13 15:26:33 UTC Comment hidden (obsolete)
Comment 9 Stefan_Lange_KA@T-Online.de 2021-07-13 20:27:08 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2021-07-14 03:34:40 UTC Comment hidden (obsolete)
Comment 11 Miklos Vajna 2021-07-14 07:18:52 UTC Comment hidden (obsolete)
Comment 12 Stefan_Lange_KA@T-Online.de 2021-07-14 09:01:11 UTC Comment hidden (obsolete)
Comment 13 Miklos Vajna 2021-07-14 09:05:48 UTC
This bug was marked as a regression. I understood comment 7 says at the end you get the idea why the keep ratio checkbox works the way it does in newer vs older versions, so the regression concern is addressed.

Feel free to file a follow-up non-regression bug in case you have further concerns; alternatively you can also mark this bug as a non-regression and reopen it. Thanks.

And yes, you're right, the only change is that the setting no longer reset to "false" after restarting Writer. Anything else: it's as good/bad as it was before.
Comment 14 Stefan_Lange_KA@T-Online.de 2021-07-14 12:07:20 UTC
The main problem (see the title of the bug report) is that width and height are set equal when Keep Ratio is switched on and position (left, right etc.) or anchoring (page, paragraph etc.) are changed - or Keep Ratio is switched off. Ratio is not kept but set to 1!

IMHO these actions never should change the size of the image even if Keep Ratio is switched on or off.
Keep Ratio only should influence the change of the image size (width and height are changed proportionally [on] or not [off]).

The erroneous behavior is new and it was introduced with LO 7.2. Therefore I think it is correct when I reopen the bug with the marker "regression".
Comment 15 Telesto 2021-07-14 12:45:42 UTC
(In reply to Stefan_Lange_KA@T-Online.de from comment #14)
> The main problem (see the title of the bug report) is that width and height
> are set equal when Keep Ratio is switched on and position (left, right etc.)
> or anchoring (page, paragraph etc.) are changed - or Keep Ratio is switched
> off. Ratio is not kept but set to 1!
> 
> IMHO these actions never should change the size of the image even if Keep
> Ratio is switched on or off.
> Keep Ratio only should influence the change of the image size (width and
> height are changed proportionally [on] or not [off]).
> 
> The erroneous behavior is new and it was introduced with LO 7.2. Therefore I
> think it is correct when I reopen the bug with the marker "regression".

Lets set it simply to NEW. This is a true bug. 

1. Open attachment 173542 [details]
2. Select the image -> Image properties
3. Type Tab
4. Ratio is disabled (in this document)
5. Say you want to resize: select keep ratio
6. Resize Height or width -> (fine)
7. Press OK
8. Reopen the Image properties dialog (keep ratio checked)
9. Click inside the Height box (or select the Margin drop down'). Now it's broken
Comment 16 Telesto 2021-07-31 08:51:19 UTC
1. Open attachment 173985 [details] (this simply another file.. not that important)
2. Select the image and press F4
3. Type tab
4. Check keep ratio
5. Press OK
6. Press F4 again
7. Uncheck keep ratio

Height changes from 8,25 to 5,54 cm
Comment 17 Stefan_Lange_KA@T-Online.de 2021-08-28 11:23:38 UTC
After I have reproduced the bug some days ago still with LO 7.2.0 release I have retested today [28.08.2021] with recent builds (7.2.1 rc1, dev 7.2.2, dev 7.3.0). In these tests the problem occured no longer - neither with my own files (test and "productive") nor with the simple test file attached by Telesto (see Comment 16).
Therefore I change the status to RESOLVED WORKSFORME. OK?
Comment 18 Telesto 2021-08-28 17:33:29 UTC
(In reply to Stefan_Lange_KA@T-Online.de from comment #17)
> After I have reproduced the bug some days ago still with LO 7.2.0 release I
> have retested today [28.08.2021] with recent builds (7.2.1 rc1, dev 7.2.2,
> dev 7.3.0). In these tests the problem occured no longer - neither with my
> own files (test and "productive") nor with the simple test file attached by
> Telesto (see Comment 16).
> Therefore I change the status to RESOLVED WORKSFORME. OK?

Based on the range I would say it was fixed by bug 143633. But need reverse bibisect to be sure..