Steps: 1) Open Writer 2) Draw an object like a circle or rectangle 3) right-click > Position and size 4) Check 'keep ratio' and press OK 5) Resize object Result - ratio not preserved when resizing object Workaround - resize with the mouse holding shift Tested in 3.3.0 and master on Linux.
Samuel, could you please take a look at this? When 'keep ratio' is checked, resizing by dragging the corner should keep the ratio locked. When it's unchecked, dragging should not preserve the ratio. Holding down shift should reverse this behavior. This is how other office suites work like Kingsoft Office.
The checkbox in MS Word 2013 "Position and Size" -> 'lock ratio' is also respected when resizing. Pressing shift also reverse the behavior. Ignoring this parameter is clearly a bug.
I think this checkbox is only valid when you enter the width/height manually in the text entries above the checkbox. When you resize with the mouse, you can keep the aspect ratio by holding shift. Maybe this checkbox should be made like it is in GIMP: https://www.packtpub.com/sites/default/files/Article-Images/2022_04_02.png
Created attachment 107017 [details] Sample DOCX showing "keep ratio" property lost on import Samuel, I understand LO is using "keep ratio" as a UI element in the dialog. However, from a user's prospective when a picture has a property "keep ratio", he expects the application to respect that property. This is how all of the other office suites behave and the logical behavior. I understand it may not be easy to fix, but addressing it would give us 1) more intuitive UI 2) better interoperability For example in the attached file, the aspect ratio properties are lost on import into Writer, but Word remembers them between saves.
In an offline discussion about the required changes in the ODF spec to implement this, Miklos said, First step is to have an implementation for the new attribute in our loext namespace. https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes
I doubt this needs to be implemented in ODF, the same way as when images now scale proportionately. It should also be noted that the checkbox does also appear in the side.
Jay, Did you try using the attached doc in either Kingsoft Writer or Word? When resized by dragging, one image scales proportionally, while the other does not. This is because "keep ratio" is part of the doc/docx spec and other office suites respect it's value. Are you saying that this information should be discarded between saves? Or only remember the "keep ratio" parameter when saved in .docx format? Currently, without actually being associated with the underlying image, "keep ratio" is just a confusing UI element.
Doing it like GIMP would be a bad choice. GIMP's UI is setup that way because it's only keeping track of one image per document. If you have multiple images per document, it should be done the way MS Word does it.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
Very confusing UI and still an issue with Version: 5.1.0.0.alpha1+ Build ID: f830600ece806ec365a4839e79afabe183c5e36d
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
No support for this feature in 5.4
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
No support for this feature in 6.0
Reproduced with a shape in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 002f941ec20e594e9702c39fab9cf9f4cc392dab CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Even more confusing to the user when the sidebar (Properties deck > Position and Size section) has the option ticked, but the handles still resize freely.
*** Bug 160752 has been marked as a duplicate of this bug. ***
*** Bug 163934 has been marked as a duplicate of this bug. ***
Wouldn't this basically be superseded by bug 84565, which calls for the property to become a part of the data of each object? I mean the current summary is not correct as there is no object attribute to ignore. But if such an attribute would be introduced, it would make sense to delete the current separate mouse-handling code.
(In reply to Buovjaga from comment #18) > Wouldn't this basically be superseded by bug 84565, which calls for the > property to become a part of the data of each object? I mean the current > summary is not correct as there is no object attribute to ignore. But if > such an attribute would be introduced, it would make sense to delete the > current separate mouse-handling code. Sorry, made this comment in ninja edit mode accidentally.
> However, from a user's prospective when a picture has a property "keep > ratio", he expects the application to respect that property. This is how all > of the other office suites behave and the logical behavior. > I couldn't agree more.