Created attachment 165853 [details] File for reproducing the bug Open attached file. It has three shapes. All of them are anchored as "To cell (resize with cell)". The blue shape is the "original" rectangle. The green shape was created from it by slant with 45° and to get the olive shape this was then rotated by 60°. Hide row 7. The shapes adapt as expected. Save the file using File > Save a copy. Keep the current file open. Now open the saved file and compare it with the already open file. You will notice the distortion immediately. If a shape is anchored as "To cell (resize with cell)", then position and size is given in the file by start and end cell and offsets relative to the left top corner of start and end cell. If a shape gets a transformation, LibreOffice starts with a rectangle, that has the cell corner as left/top corner, and LibreOffice integrates the needed shift into the final translation. From the values in the file I guess, that it was forgotten to subtract the start offset values from the end offset, when instead the start offset the values 0|0 are used. So the initial rectangle is too wide and too high. The blue rectangle is not transformed and has a different error, I guess for that shape the import is wrong. I have only kept it in the example file, that you can reproduce, how the green and olive shapes were generated.
Created attachment 166671 [details] Screenshot of distortion Repro. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: ccdb78773ac6c9d19140e8084f37cc2c7f06240e CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 18 October 2020 Arch Linux 64-bit Version: 7.0.2.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); Käyttöliittymä: fi-FI 7.0.2-2 Calc: threaded
I bisected with win64-6.4 the distortion change to your commit https://git.libreoffice.org/core/commit/7efd182997cb29ed4820145efc99a6c18e2c3303 I guess it can't be called a regression because the earlier original rendering was so off.
I'm currently examine the position and size problems in Calc again. I will try to find the reason here, but I will not assign it to me until I know, what is going on here.
If a row/col is hidden, shear and rotation angle need to be adapted in the object geometry. Otherwise rendering of the object would not reflect the new size. In file format, the shape has to be stored, as if no row/col are hidden. That means, that before the geometry is written to file, the adaption to hidden row/col has to be inverted. It seems, that is missing.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd966aac6ecd8ce606ac3f2ccd602e467114ba3f tdf#137033 improve save of 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.
Problems in right-to-left sheets will be handled separately. So this is fixed so far.
Verified in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 6ce66560c59470a9eb76fbf80f439b452166d3e4 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/ad2184eadafcb92ed196ecea69aa7b67bdefb3fc tdf#137033 improve save of 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.