Bug 162797 - Images anchored with cell getting stacked at one place at large y positions in xlsx file.
Summary: Images anchored with cell getting stacked at one place at large y positions i...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.2.5.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2024-09-04 17:59 UTC by Avinash Thakur
Modified: 2024-09-22 14:56 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Sample generated by xlsxwriter (97.59 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2024-09-04 18:11 UTC, Avinash Thakur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Avinash Thakur 2024-09-04 17:59:51 UTC
Description:
ref: https://github.com/jmcnamara/XlsxWriter/issues/1089

If I add an image at a position where y > 2147483648 (2**31), the image doesn't get rendered at the expected position.
Note: The value of y is in the file in character(?) units.

In UI, I can move the image downwards but when I save and reopen, the image moves back to it's original position.

As I documented in the referenced issue, it appears that we are using a signed 32 bit integer to get this value and probably preventing integer overflow. Just a guess though.

Steps to Reproduce:
1.Create a blank Spreadsheet
2.Add an image in the last row and anchor it to the cell
3. Save and reopen the file


Actual Results:
Observe that the image has moved somewhere else (near 13212 cell in default row height)

Expected Results:
The image should stay as it was placed.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 480(Build:3)
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-IN (en_IN.UTF-8); UI: en-US
Ubuntu package version: 4:24.8.0~rc3-0ubuntu0.24.04.1~lo2
Calc: threaded
Comment 1 Mike Kaganski 2024-09-04 18:09:07 UTC
A sample XLSX with such a problem (generated by XlsxWriter?) would be nice.
Comment 2 Avinash Thakur 2024-09-04 18:11:36 UTC
Created attachment 196235 [details]
Sample generated by xlsxwriter
Comment 3 Avinash Thakur 2024-09-04 18:13:36 UTC
@mike(In reply to Mike Kaganski from comment #1)
> A sample XLSX with such a problem (generated by XlsxWriter?) would be nice.

I added the attachment - the file generated from xlsxwriter.

However, the steps in description might be more convenient to recreate the bug and show that xlsxwriter is not the culprit.
Comment 4 Mike Kaganski 2024-09-04 20:19:32 UTC
Of course xlsxwriter is not the culprit - it's known; drawingml import uses UNO API to set the coordinates and sizes; and that is 32-bit.

The file is needed for convenience of testing, to avoid the steps.
I set to NEW, but I bet there's already a duplicate.