Bug 149840 - FILEOPEN DOCX SmartArt background shape has wrong size
Summary: FILEOPEN DOCX SmartArt background shape has wrong size
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) alpha0+
Hardware: All All
: medium normal
Assignee: Regina Henschel
Whiteboard: target:7.5.0
: 79944 (view as bug list)
Depends on:
Blocks: OOXML-SmartArt
  Show dependency treegraph
Reported: 2022-07-04 09:37 UTC by Regina Henschel
Modified: 2023-01-30 08:45 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

SmartArt with background (23.95 KB, application/zip)
2022-07-04 09:37 UTC, Regina Henschel
Screenshot comparing Word with LO (64.29 KB, image/png)
2022-07-04 09:48 UTC, Regina Henschel
Wrong width of elements in SmartArt (58.72 KB, application/zip)
2022-07-10 18:42 UTC, Regina Henschel

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2022-07-04 09:37:57 UTC
Created attachment 181103 [details]
SmartArt with background

Make sure that the option "SmartArt to LO shapes or reverse" is checked in "Microsoft Office" section in "Load/Save" in Tools/options.

Open attached document. It has a SmartArt with green background. You will see now background. Reason is, that the background is imported with a 4x4 size. You can examine it with the Developer Tools.
Comment 1 Regina Henschel 2022-07-04 09:48:54 UTC
Created attachment 181104 [details]
Screenshot comparing Word with LO

The wrong text direction is a different error and likely covered by bug 149809 and/or bug 149551.
Comment 2 Rafael Lima 2022-07-04 13:48:24 UTC
I can confirm this with

Version: / LibreOffice Community
Build ID: 61f5c991a97de8990badfed6ef840941b5aa8c7f
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded

The green background is not visible after import. But it is visible if the file is opened with MSO Word.
Comment 3 Regina Henschel 2022-07-10 18:42:08 UTC
Created attachment 181208 [details]
Wrong width of elements in SmartArt

Open the attached document. It has a SmartArt and a screenshot of it. Notice that the circles are distorted to ellipses. 

It seems an underlying problem is, that the group, which represents the SmartArt, does not get a size. And therefore it is not possible to assign the correct size to the background shape, e.g in AddShape() in oox.

I have put the example not into a new bug report, because I suspect, that it has the same reason. At least, if I add the size in GraphicImport(), the elements are circles as it should be. But I get other import problems, so I have no solution.
Comment 4 Regina Henschel 2022-10-02 20:27:10 UTC
@Armin: This is the problem I told you about at the LibreOffice Conference.
Comment 5 Regina Henschel 2022-10-08 12:46:14 UTC
I have tried to set the size by setting the logicRect of the background shape around line#974 in writerfilter/source/dmapper/GraphicImport.cxx. That gives indeed a correct size of the background shape, but the size if the SmartArt shapes are still wrong. So this is likely the wrong place for a fix. For testing use a SmartArt with non default shape width or height in the SmartArt components.
Comment 6 Regina Henschel 2022-10-10 12:25:28 UTC
The shape mpShape in ShapeContextHandler::getDiagramShapeContext() needs the size as given in cx and cy in document.xml in the docx file markup.
I'll try to transport that info from writerfilter to oox.
Comment 7 Commit Notification 2022-10-13 06:57:13 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":


tdf#149840 Use actual outer size for SmartArt in Writer

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 8 Xisco Faulí 2023-01-30 08:45:02 UTC
*** Bug 79944 has been marked as a duplicate of this bug. ***