Created attachment 168969 [details] Spreadsheet with 30mm row height and 80mm column width Open attached spreadsheet in LO-daily, go to cell B2 and insert an image. Error: The image size and position is totally wrong. Open attached spreadsheet in LO 7.0, go to cell B2 and insert an image. It works there. Save the file. Open the saved file in LO-daily. The image position looks good at a first glance. But now open the Position&Size dialog. You will see negative values for y-position and height. This looks like an integer overflow somewhere. The spreadsheet has row height 30mm and col width 80mm (79,99mm) for all cells. Such dimensions are not uncommon when users use a spreadsheet for e.g. a material catalog. I see the error in Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL It is OK in Version: 7.0.0.2 (x64) Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
The error comes in this way (values as I see them in VS when loading the file): On loading the file: ScTable::SetDrawPageSize calculates (with considering row height and column width) tools::Long x = 8191217 tools::Long y = 3146121216 Then it builds Size(x,y) and calls ScDrawLayer::SetPageSize That makes pPage->SetSize(), which is a call to Sdr::SetSize() And there are assignments mnWidth = aSiz.Width(); mnHeight = aSiz.Height(); But the members mnWidth and mnHeight are of type sal_Int32. That results in mnHeight = -1148846080. And this negative page height is used in ScLimitSizeOnDrawPage in fuins1.cxx, when the image is inserted and gives the wrong pos and size of the image. A fix is beyond my current skills.
Confirmed opening and inserting. Confirmed doing and saving with 6.4 and opening with 7.1 and 7.2 Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 4; OS: Windows 10.0 Build 21292; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL and Version: 7.1.1.0.0+ (x64) / LibreOffice Community Build ID: b1ee85d5c19466fb65d934491639fd4f2769fe13 CPU threads: 4; OS: Windows 10.0 Build 21292; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL Looks fine with Version: 7.0.5.0.0+ (x64) Build ID: e29387a749edb1bf39ca2b558099964da42b3a4b CPU threads: 4; OS: Windows 10.0 Build 21292; UI render: Skia/Raster; VCL: win Locale: en-GB (es_ES); Interfaz: es-ES Calc: CL
On Linux I can reproduce "Open attached spreadsheet in, go to cell B2 and insert an image." with 4.1
Like raal, I see the problem in older versions. 6.3 repo oldest, 7.0 repo oldest & master. Is the working state seen only on Windows?
There may be cases when a bug was fixed in one commit, but reverted shortly later. For me, this bug appears in 6.1 repo, in linux. However, need someone to test if it worked someone in the 7.0 repo. This kind of issue can not be Windows-only, but I may be wrong. Set platform to all as the bug itself affects linux also, even though it seems hard to bibisect on linux.
I tried to bibisect in Linux but I can't see it OK in 7.0 and not in 43all. Drag&drop inserts image, but with wrong size and position. I remove bibisectRequest as it appears in searches, just put possibleRegression.
Hi, I have a bug in LO 7.3.4 that may be related : in a speadsheet, I insert a small image 2cm height (anchored to the cell). I can move it around. Then I select all rows and set row height to 2,1 cm. If I try to move again the image it gets stuck in the first row. If I cancel the row height setting operation : no change. Workaround : if I set again the row height to 4,5 cm or more, I can move again the image freely.
*** Bug 163278 has been marked as a duplicate of this bug. ***