Description: Image doesn't fit frame after downsizing the image by dragging frame border and saving as DOCX Steps to Reproduce: 1. Open attached file 2. Select the image frame. Drag it inwards so the image shrinks 3. Save 4. File reload Actual Results: Small frame with zoomed in image Expected Results: Same result as before save and reload Reproducible: Always User Profile Reset: No Additional Info: Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5c7b3f5dc1f14081eed380999dc029a500784d55 CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 200858 [details] Example file
It's fine in Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded In the sense that moving the frame border didn't shrink the image. The new behaviour is nicer, but results in surprises when saving to DOCX
Hi Telesto, Thank you for reporting the bug. Unfortunately the file appears the same before and after reloading for me; I cannot reproduce the bug in Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 94231af057db7871fb993582e2015c0fa21dde46 CPU threads: 16; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 200874 [details] Sample
Adjusted steps 1. Open the attached file 2. Select the image 3. Insert -> Caption -> Add some caption title and press OK 3. Select the image frame. Drag it inward. Frame and image are both shrinking 4. Save 5. File -> Reload
Hello Telesto, Thank you for reporting the bug. I can confirm that the bug is present in. Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 22; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded and Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 19f3b72f34c487dc97d582712d21734a7e055fd5 CPU threads: 22; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Also in Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Fine in Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Version: 7.2.0.0.alpha0+ (x64) Build ID: 3dc2e629b247873bfbd3190c11152d8d2bab1a03 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL author Mike Kaganski commit 3dc2e629b247873bfbd3190c11152d8d2bab1a03 tdf#138953: use original (cropped, but unrotated) object size in spPr This not only fixes the regression from b226383a83e41bbced9fc2a02dc09a449401ec97, but also makes the written size more correct than before, when it was slightly larger compared to original object size. Corrected unit test for tdf#116371 reflect that: the object in ODT is 241.78 mm x 240.61 mm. It previously was exported as 241.88 x 240.70; now the exported size is closer: 241.79 x 240.63. Change-Id: Ibfe85c7cd98c089e58af8d7f3848990af8e1100f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107957
*** This bug has been marked as a duplicate of bug 145542 ***