Created attachment 170922 [details] Scaling a group with transformed child elements Open attached document. It contains a group with two child elements. One is flipped and the other is rotated. There is screenshot where the group should be. The screenshot looks gray, because I have reduced its contrast. One place were an error happens is statement aTransformation = aParentTransformation*aTransformation; in shape.cxx https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/shape.cxx?r=3e4eb070#821 Here aParentTransformation is a scaling matrix from the group and aTransformation contains the rotation of the green shape. When they are multiplied, they introduce a skew. Word cannot handle skew at all, but LibreOffice can. Therefore the scaling has to be applied before rotation. There are surely other error in addition, but this one I could identify. Look at it with 96dpi, then the screenshots have the correct size and position and you can see, were the shapes should be.
Created attachment 171301 [details] Comparison LibreOffice 7.2 master and MSO 2010
Reproduced in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: a199e4ea389c934d169a178433f4b94033e60f93 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Hi Regina, Since you provided a code pointer, can we turn this issue into an easyhack ?
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
(In reply to Xisco Faulí from comment #3) > Hi Regina, > Since you provided a code pointer, can we turn this issue into an easyhack ? I still want to implement the import of 3D extrusion. That will touch the same area of code, and I want to have this bug to be fixed before. So I think, it is not suitable for an easyhack, because that might linger around years. Or do you have someone who wants to work on it now?
Likely not an easy hack at all, but I have an idea and will try to fix it together with bug 141953.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/36499d8bf6cd5c6af7b2ceb6071baf5c7421bd0a tdf#141463 avoid skew in shape group in ooxml import .. 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.
When you open the example document, you will notice, that the erroneous skew is fixed, but that the shape has a wrong position. I will track the wrong position in a new bug report.
Follow up bug for wrong position is bug 142304.
*** Bug 93952 has been marked as a duplicate of this bug. ***
Verified in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: c781776f3c79bbe3175b1452d26c79ebb931a500 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Regina, thanks for fixing this issue!!
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/ac0eb504a38321849b854889598a28d0687196ea tdf#141463 avoid skew in shape group in ooxml import .. 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.