Bug 140355 - Images in frame growing after DOCX export
Summary: Images in frame growing after DOCX export
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, implementationError
: 140370 142819 (view as bug list)
Depends on:
Blocks: DOCX-Images
  Show dependency treegraph
 
Reported: 2021-02-11 20:11 UTC by Telesto
Modified: 2022-11-25 08:14 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (205.93 KB, application/vnd.oasis.opendocument.text)
2021-02-11 20:11 UTC, Telesto
Details
The original file and its docx version in Writer (223.06 KB, image/png)
2021-02-16 07:31 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-02-11 20:11:31 UTC
Description:
Images in frame growing after DOCX export

Steps to Reproduce:
1. open the attached file
2. Save a copy as DOCX
3. Open the DOCX
4. Flip flop between ODT & DOCX.. notice difference in size of the image in frame

Actual Results:
Different size

Expected Results:
Image size should be stable


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
7.2

still OK in
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 568b820bc2d52c007ee08ad7a3849c94a458115d
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 1 Telesto 2021-02-11 20:11:45 UTC
Created attachment 169693 [details]
Example file
Comment 2 NISZ LibreOffice Team 2021-02-16 07:31:17 UTC
Created attachment 169774 [details]
The original file and its docx version in Writer

Confirming in:

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 28555fc345ac2ccdda0e4e0f3c812c646befe68b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-GB
Calc: CL

The images are cropped here. The bottom most one has 67% of width and 71% of height of the original size. Also "Keep scale" is set.

In 7.0 and before both were exported as 67%, i.e. the width was correct and the height was not. 
This changes in 7.1 and now both values are 71%, i.e. the height is correct and the width is not.
Comment 3 Gabor Kelemen (allotropia) 2021-02-16 22:25:53 UTC
Seems that the behavior changed (it was not correct before either, so I remove regression keyword) in 7.1 with:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=3d7c90b45c607fe560bacd8f57de0966a93edb4d

author	Mike Kaganski <mike.kaganski@collabora.com>	2020-12-18 13:12:50 +0300
committer	Mike Kaganski <mike.kaganski@collabora.com>	2020-12-22 06:37:22 +0100

tdf#138953: use original (cropped, but unrotated) object size in spPr

Adding CC to: Mike Kaganski
Comment 4 NISZ LibreOffice Team 2021-02-17 12:57:35 UTC
*** Bug 140370 has been marked as a duplicate of this bug. ***
Comment 5 Telesto 2021-02-17 18:45:14 UTC
From Bug 140370 

Created attachment 169822 [details]
The original file with slightly resized table and its docx version

This is not the usual image+caption in a frame, but images and text in a table.

Resizing the table makes the scaling of the left image change: 
from 59% width and 65% height 
to   50% width and 63% height.

The scaling export bug makes the 50% width becoming 63%, so it does no longer fit in the cell and the right side disappears. 
But manually changing the values fixes the layout for me.

I strongly believe this is another way to better visualize the scaling export problem in bug #140355
Comment 6 NISZ LibreOffice Team 2021-06-14 10:23:43 UTC
*** Bug 142819 has been marked as a duplicate of this bug. ***
Comment 7 Stéphane Guillou (stragu) 2022-11-25 08:06:24 UTC
Still reproducible with a master build from today:

Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 24d7431876e87eba700a9f141dc8e030143a92ad
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Kendy, not sure if you want to have a look, given your recent crop + DOCX rountrip fix?