Created attachment 156505 [details] screenshot Steps to reproduce: 1. Open attachment 141216 [details] from bug 116892 2. Save it as .ODS 3. Open the new generated document -> The drawing is a line. See screenshot Reproduced in Version: 6.5.0.0.alpha0+ Build ID: 4a8d3b80283cec4a93dd697eab70afcb82f04f4f CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f44140bebb9c493d97ba5aef26c9692c53a6b93f author Regina Henschel <rb.henschel@t-online.de> 2019-11-28 19:28:29 +0100 committer Regina Henschel <rb.henschel@t-online.de> 2019-12-11 23:42:39 +0100 commit f44140bebb9c493d97ba5aef26c9692c53a6b93f (patch) tree 6673c5852aed328a2d884f8615bb84a3a86a28c3 parent 2ae964f88a4f1002a4fd8a804a079559c3d64196 (diff) tdf#119191 Implement SdrObjCustomShape::AdjustToMaxRect Bisected with: bibisect-linux64-6.5 Adding Cc: to Regina Henschel
Created attachment 156513 [details] shape anchored to cell but without resize I think, there is a problem with the "end" values in the shape. I have attached a file, which has the same settings. Only the shape is anchored to cell, but not with "resize with cell". Therefore in file format the attributes "table:end-cell-address", "table:end-x" and "table:end-y" are missing. The file has in addition a group of rectangles to indicate the cells and the shape and the snap-rectangle of the shape. That group is anchored to page. Open the file with my patch or a Daily without my patch or with LO 6.1, which had been the start creator version of the document. Then set the shape to anchor to cell _with_ resize and resave. That creates the above mentioned attributes. Now unpack the file and compare the original values with the new generated. In the original document they are address B3, x=36.57pt=12.90mm, y=3.66pt=1.2916mm The new created values are address C4, x=5.32mm, y=0.89mm. The ODF 1.2 specification says (19.627, 19.632, 19.633): <quote> The table:end-cell-address attribute specifies specify end position of the shape if it is included in a spreadsheet document. The table:end-x attribute specifies the x-coordinate of the end position of a shape relative to the top left edge of a cell. The size attributes of the shape are ignored. The table:end-y attribute specifies the y-coordinate of the end position of a shape relative to the top left edge of a cell. The size attributes of the shape are ignored. </quote> I think, that the error is not in my patch, but might become visible now. I think the error is in the way these "end" values are calculated and used. The old values would generate a nearly zero width of the shape, and the new created values seem to be wrong too.
In my tests I have got faulty "end"-values, when I made a change to the shape and then save the document while the shape is still selected. It seems, that it is necessary to deselect the shape to refresh all internal states. Otherwise an inconsistent state is saved to file, which then results in a damaged shape on reload.
(In reply to Regina Henschel from comment #3) > In my tests I have got faulty "end"-values, when I made a change to the > shape and then save the document while the shape is still selected. It > seems, that it is necessary to deselect the shape to refresh all internal > states. Otherwise an inconsistent state is saved to file, which then results > in a damaged shape on reload. Thanks for the clarification. I believe we can close this issue as RESOLED INVALID then