Description: In Writer, if you have a document where you insert a JPEG photograph, and ... 1. Select the photograph 2. R-click to display the context menu 3. Select Properties > Image Type > Size 4. Select “Keep ratio” as well as BOTH “Relative to” check-boxes 5. Increase either Width or Height to some larger (or smaller) percentage 6. Press OK You will notice that the photograph does NOT keep the original ratio and is horribly distorted. Things work as they should as long as you do NOT have BOTH “Relative to” check-boxes selected before you press OK. It is not intuitive to have do deselect something after having selected it to make a necessary change. Steps to Reproduce: 1. Select a JPEG photograph in a Writer document 2. R-click to display the context menu 3. Select Properties > Image Type > Size 4. Select “Keep ratio” as well as BOTH “Relative to” check-boxes 5. Increase either Width or Height to some larger (or smaller) percentage 6. Press OK Actual Results: The "Keep ratio" function works fine if both "Relative to" check-boxes are NOT selected before pressing OK; otherwise, the image is distorted. Expected Results: Image does not maintain the original height/width ratio. Reproducible: Always User Profile Reset: Yes Additional Info: I notice that this bug has been around since at least 2014!!! I would have updated that first posting with a confirmation; however, it seems nobody is taking this bug seriously and have long since forgotten about it. Version: 7.2.3.1 (x64) / LibreOffice Community Build ID: 1d5dee817bde88d78dbcc0d00f88492568e131d5 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Just for the record, on Win10 with master sources updated recently, I don't reproduce this. I gave a try on pc Debian x86-64 with master sources updated today and with LO Debian package 7.2.2 and gen rendering (to be closer to Windows), I don't reproduce this. I tried with Relative to "Paragraph area" and "Entire page". (I tried with a jpg file)
(In reply to Julien Nabet from comment #1) > Just for the record, on Win10 with master sources updated recently, I don't > reproduce this. > I gave a try on pc Debian x86-64 with master sources updated today and with > LO Debian package 7.2.2 and gen rendering (to be closer to Windows), I don't > reproduce this. > I tried with Relative to "Paragraph area" and "Entire page". > (I tried with a jpg file) I simply do not understand how you could not reproduce this error, as it happens 100% of the time for me over these past several days. I am not sure what you mean by "master sources", but I have Windows 10 v. 21H2 as of 20 Nov 2021. Three days after that update, I had the Cumulative Update Preview for Win10 as well as for the .NET framework for 3.5 and 4.8 (Is it just me, or is it rather strange that a preview comes out three days after the major update?). I have LO v. 7.2.3.1 (x86), but that should not matter because I saw bug reports dating back to at least 2014. I did not even bother writing up the bug reports for several other major issues I found while working on trying to place images in my documents, specifically with regards to the functionality of frames and captions, neither of which work as expected or desired. When I first made the switch to LO over a year ago, I discovered the text tearing and resizing issue only to find that it too had been written up previously--but never fixed. The LO feeling seemed to be that it is not that big an issue because it only allegedly happens to less than 5% of the users. Yet, it happens to me countless times every day without fail. Drives me nuts. I literally spent all day, every day, for a week or more trying every possible combination of settings in the tools menu and the styles settings to no avail. I suspect it may be because LO is using an integer data type instead of a floating point data type like double, but that is just speculation on my part (I am presuming the use of C++). If it were just the big, complicated issues, that would be one thing, but, it is also all the little, seemingly quick fixes that do not get addressed. I wrote up a bug report on the page style margins setting for the Normal (0.75") being off on the left margin side. There is seemingly no way for the user to modify or correct this, so the easy alternative is to use the Moderate Margin setting (which is the same, albeit correct, margin setting for 0.75"). I understand that everyone has different hardware, software, personal preferences for their settings, and are themselves speaking/reading/writing in different languages, but it is still monumentally frustrating that I have over one year trying to learn this software and have barely touched Calc and Math and have not even opened the other packages that come with LO due to the extremely long learning curve associated with LO. I spend more time trying to correctly document my technical notes on various subjects of interest than I do in learning or expanding my knowledge of these subjects.
Is it possible to add an example file. Document with image.. Maybe it's some particular setting (page dimension/certain image) Currently I can't repro Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ddc57169ac8d1de00403dbb09fef5221beaa0f3d CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
(In reply to Eek! A Bug. Kill it! from comment #2) > Its still > monumentally frustrating that I have over one year trying to learn this > software and have barely touched Calc and Math and have not even opened the > other packages that come with LO due to the extremely long learning curve > associated with LO. I spend more time trying to correctly document my > technical notes on various subjects of interest than I do in learning or > expanding my knowledge of these subjects. Out of curiosity; did you ever try some different competitor word processor? Maybe slightly unexpected comment, but sounds like LibreOffice is only causing strain & unproductiveness And this is surely possible, it has quite a list of bugs left or right. Those will - sadly - be around for a while (I guess), mainly because a lack of developers (or paying customers wanting a fix).
Created attachment 176577 [details] Example file Ok, I can reproduce this.. 1. Open the attached file 2. Select the top image 3. Press F4 (type tab) 4. Replace 54% width with Width 25% 5. Press OK 6. Press F4 (type tab) 7. Replace 25% with 54% 8. Press OK (first & second image should be same dimensions they are not) Press Original Size (type tab) button at for both images & press OK in both cases Repeat 3-7 now it seems to be OK. So this happens when you shrink the image first (dragging) image size followed by using the dialog
Created attachment 176578 [details] Example file Next try 1. Open the attached file 2. Enlarge the image by dragging one of the corners 3. Copy the image 4. Paste one below (as reference) 5. Select top image 6. Press F4 type tab 7. Remember the existing width (A) & replace it with say 15 8. Press OK 9. F4 again 10. Restore the width to (A) 11. Press OK Notice the size difference Worst when using width 1%
1. Open the attached file 3. Copy the image 4. Paste one below (as reference) 5. Select top image 6. Press F4 type tab 7. Remember the existing width (A) & replace it with say 15 8. Press OK 9. F4 again 10. Restore the width to (A) 11. Press OK 12. Drag copy image over the resized image and notice differences
(In reply to Telesto from comment #7) > 1. Open the attached file > 3. Copy the image > 4. Paste one below (as reference) > 5. Select top image > ... why not but above all, do you reproduce the initial pb with "Select “Keep ratio” as well as BOTH “Relative to” check-boxes" ?
(In reply to Julien Nabet from comment #8) > (In reply to Telesto from comment #7) > > 1. Open the attached file > > 3. Copy the image > > 4. Paste one below (as reference) > > 5. Select top image > > ... > > why not but above all, do you reproduce the initial pb with "Select “Keep > ratio” as well as BOTH “Relative to” check-boxes" ? Yes AR is off (but needs side by side view to tell in certain cases) Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ddc57169ac8d1de00403dbb09fef5221beaa0f3d CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Also found in 3.5.7.2 Looks like rounding issues; changing width percentage changes height, height doesn't have decimal level (rounding). Scaling back up, and everything is off?
(In reply to Telesto from comment #9) > (In reply to Julien Nabet from comment #8) > .. > Yes AR is off (but needs side by side view to tell in certain cases) "AR" ?? What do you mean?
(In reply to Julien Nabet from comment #10) Sorry, aspect ratio
(In reply to Telesto from comment #11) > (In reply to Julien Nabet from comment #10) > Sorry, aspect ratio I'm not sure to understand the whole thing. I asked: "do you reproduce the initial pb with "Select “Keep ratio” as well as BOTH “Relative to” check-boxes"" You responded "Yes AR is off (but needs side by side view to tell in certain cases)." So you reproduce the pb with "Select “Keep ratio” as well as BOTH “Relative to” check-boxes" since you said "Yes". But about "AR is off.... " I don't know what you're talking about even after you indicated AR is "Aspect ratio". Anyway it's not important, let's put this one to NEW since you reproduced this. I can't help here since it's not a crash and don't reproduce this => uncc myself.
Reproduced with Telesto's steps in comment 7. Originally, the width is 59% and the height 36%. Setting it to a width bigger than 100% (e.g. 120%), applying, and then back to the original 59% will result in a height of 43% (aspect ratio is lost). Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 579d144290c1617fdb38d09b30900a6bbe390b8d CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (en_AU.UTF-8); UI: en-US Calc: threaded