Bug 138769 - FILEOPEN DOCX WordArt replacement image has incorrect height
Summary: FILEOPEN DOCX WordArt replacement image has incorrect height
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: OOXML-WordArt VML-Shapes
  Show dependency treegraph
 
Reported: 2020-12-09 11:10 UTC by NISZ LibreOffice Team
Modified: 2021-11-11 13:29 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot of the original document side by side in Writer 5.4 and 6.0 (132.16 KB, image/png)
2020-12-09 11:10 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2020-12-09 11:10:30 UTC
Created attachment 167998 [details]
Screenshot of the original document side by side in Writer 5.4 and 6.0

attachment #166880 [details] contains a WordArt image at the top left corner.
This (rather its placeholder image) has incorrect height compared to Word: 1.66 cm instead of 2.59 cm. This affects the layout of the whole document.
Attachment #167937 [details] shows the document in Word and current Writer.

Steps to reproduce:
    1. open attachment #166880 [details]

Actual results:
“Rhif Number” WordArt has incorrect height of 1.66 cm

Expected results:
2.59 cm height of Wordart.

LibreOffice details:
Version: 7.2.0.0.alpha0+ (x64)
Build ID: 796c7f612603490dda9277ced0f6ab3cce3bc116
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL

Also in:
Version: 7.2.0.0.alpha0+ (x64)
Build ID: 796c7f612603490dda9277ced0f6ab3cce3bc116
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL

Was good in:
Version: 5.4.0.3
Build ID: 92c2794a7c181ba4c1c5053618179937228ed1fb
CPU threads: 4; OS: Windows 6.2; UI render: default; 
Locale: en-US (hu_HU); Calc: CL

Additional Information: 

Bibisected using bibisect-win32-6.0 to:

URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4ac38b5689458f6dc0da313fbd24b8b462cbcc78 
author	Szymon Kłos <szymon.klos@collabora.com>	2017-12-07 16:09:47 +0100
committer	Szymon Kłos <szymon.klos@collabora.com>	2017-12-08 21:18:13 +0100

tdf#114308 Export Watermark size as is

Adding CC to: Szymon Kłos
Comment 1 Xisco Faulí 2020-12-09 11:27:20 UTC
Reproduced in

Version: 7.2.0.0.alpha0+
Build ID: 84af20ef3ea72190784e9e7be820684c2558ba8c
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: fr-FR (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 2 Justin L 2021-11-11 12:54:20 UTC
The problem seems to be with the section "if (!moTrim.has() || !moTrim.get())"
Comment 3 Justin L 2021-11-11 13:29:54 UTC
(In reply to Justin L from comment #2)
> The problem seems to be with the section "if (!moTrim.has() ||
> !moTrim.get())"
This previously was only called when
getShapeName().match( "PowerPlusWaterMarkObject" )
but now is run regardless. That can't be right.

Szymon, please take a look and restrict to the specific use cases that are appropriate.