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 tree / graph
 
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
View All Add an attachment (proposed patch, testcase, etc.)

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.