Created attachment 168847 [details] 180 rotated smiley created with the latest greatest LODailyMaster build With the latest daily master build (7.2.0.0 alpha build 19042) I created a Calc document and added a two anchored shape which I have rotated via dialog (center rotation) by 180 degrees. After saving & reloading the shape was not displayed any longer. I think the problem can be found within the xml import as the written shape looks goood: <draw:custom-shape: svg:width="2.043cm" svg:height="2.059cm" draw:transform="rotate (-3.14159265358979) translate (3.511cm 2.259cm)">
I would say, it is an export error. The start anchor is in A2 with offset 3.511cm|2.259cm. That is absolute 3.511cm|2.711cm. The end anchor is in B6 with offset 1.255cm|0.452cm. That is absolute 3.513cm|2.712cm. That is width=0.002cm and height=0.001cm. I'll try to find the reason.
It seems, the order of actions makes a difference. First anchor "To cell (resize)" then rotate 180deg ==> shape is wrong First rotate 180deg then anchor "To cell (resize)" ==> shape is OK
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6ce66560c59470a9eb76fbf80f439b452166d3e4 tdf#139583 fix case rot 180deg for cell anchored shapes 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.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/2383bb3dfe489309b1b57b95bfec56b4967610fb tdf#139583 fix case rot 180deg for cell anchored shapes It will be available in 7.1.1. 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.
Many thanks for fixing this issue. Regina you are right, the order is important as the transform attribute is specified as followed: ... The draw:transform attribute specifies a list of transformations that can be applied to a drawing shape. The value of this attribute is a list of transform definitions, which are applied to the drawing shape in the order in which they are listed. ... In my logic the origin is the start cell. Then I would take the pos and size of the shape. After that I would apply the transformation attributes in the correct order. But this leads to another result. You are completely ignoring the svg:width and svg:height and are recalculating this size by the offset to the end cell. So in my opinion, the width and height attributes should not be saved if the table-end attributes are available this might prevent to use a wrong algorithm.
Having no width and height gives currently problems in import. No width or height results in zero size. And https://opengrok.libreoffice.org/xref/core/xmloff/source/draw/ximpshap.cxx?r=917338c6#524 forces zero width or height to 1. But with size 1x1 the transformation matrix is wrong in regard to rotation and shear angle. And we cannot use start or end address in SdXMLShapeContext because they are not known there, but only in module sc. When I changed the import to use start and end address to be ODF conform, I had tried examples, where I had removed width and height. But I got the mentioned problems. And because I first want to get the Calc specific handling correct, I have not changed writing width and height. In addition writing width and height helps older versions to read such documents. Work on shapes in Calc is not yet finished. There exist several RTL related problems. I'm currently investigating them. BTW: I'm curious, are you "sj" from StarOffice?