Bug 141540 - FILEOPEN DOCX rotated group has wrong size
Summary: FILEOPEN DOCX rotated group has wrong size
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.4
Keywords:
: 141330 (view as bug list)
Depends on:
Blocks: DOCX-Grouped-Shapes
  Show dependency treegraph
 
Reported: 2021-04-07 15:48 UTC by Regina Henschel
Modified: 2021-06-19 21:53 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Rotated group with rectangles and lines (41.12 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-04-07 15:48 UTC, Regina Henschel
Details
Group with a rotated content (18.00 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-04-07 15:53 UTC, Regina Henschel
Details
Comparison LibreOffice 7.2 master and MSO 2010 (113.22 KB, image/png)
2021-04-07 16:35 UTC, Xisco Faulí
Details
How it looks after 2a70cfb09c (20.97 KB, image/png)
2021-05-06 15:01 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2021-04-07 15:48:45 UTC
Created attachment 171008 [details]
Rotated group with rectangles and lines

Open attached document. It has a rotated group with yellow objects and a screenshot in blue. The screenshot is behind the group, so when all is OK, you should not see the screenshot.

A not suitable outer size is set for the group. The content of the group is fit to this size, which results in the shew.

In docx the position and size attributes refer to the unrotated group rectangle. In LO position and size refer to the snap rect of the group. In case the group is not anisotropic stretched (which is usually the case), the import in Shape::createAndInsert() produces the correct size and position. Impress uses Shape::createAndInsert() too and shows the group correctly.

The error is in GraphicImport::lcl_attribute(), case NS_ooxml::LN_shape.
Lines 788-794 are:
788    awt::Size aSize(m_xShape->getSize());
789
790    if (m_pImpl->isXSizeValid())
791       aSize.Width = m_pImpl->getXSize();
792    if (m_pImpl->isYSizeValis())
793       aSize.Height = m_pImpl->getYSize();

#788 gets the correct size from m_xShape, which considers content and transformation. But that is overwritten with the size in m_pImpl, which is the value from the ext-element from file.

If you comment out #790-793, you can see, that the group is then rendered with the correct size. But that is not a complete solution, because the position is still wrong. Besides that I do not know, which other consequences such change has.

[Anisotropic stretched groups have an additional error in Shape::createAndInsert(), which is tracked in bug 141463.]
Comment 1 Regina Henschel 2021-04-07 15:53:42 UTC
Created attachment 171009 [details]
Group with a rotated content

The group contains a red rectangle in size (as in Word) of the group and a green rectangle. The green rectangle is rotated and overflows the group rectangle in Word. This situation triggers the same error, the content is fit to the group rectangle and thus the red rectangle has wrong size and the green rectangle is skewed.
Comment 2 Xisco Faulí 2021-04-07 16:35:00 UTC
Created attachment 171010 [details]
Comparison LibreOffice 7.2 master and  MSO 2010
Comment 3 Xisco Faulí 2021-04-07 16:35:13 UTC
Reproduced in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: c47ad11f8c2e917adebbd5d7b3a3ef6cc4b3e670
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 4 Xisco Faulí 2021-04-07 16:36:50 UTC
Also reproduced in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 5.7; Render: default; 

and

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Comment 5 Commit Notification 2021-04-22 08:12:54 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2a70cfb09c4d89154d229b6a95cf076e8bd76798

tdf#141540 fix docx import of group or line with rotation

It will be available in 7.2.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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Xisco Faulí 2021-05-06 14:52:38 UTC
*** Bug 141330 has been marked as a duplicate of this bug. ***
Comment 7 Xisco Faulí 2021-05-06 15:01:31 UTC
Created attachment 171703 [details]
How it looks after 2a70cfb09c
Comment 8 Commit Notification 2021-05-06 22:08:58 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/e72b36434dc299d0fb3ecc97045fbb9ca2b9abf8

tdf#141540 fix docx import of group or line with rotation

It will be available in 7.1.4.

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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Regina Henschel 2021-06-19 21:53:42 UTC
The remaining differences are due to the fact that the "center relative to column" setting was used for the horizontal alignment. That is a general problem and independent from the originally reported wrongly skew.

I have written bug 142948 for the alignment problem.

I consider the original problem fixed here.