Description: If a Writer table splits over multiple pages, and a cell is merged that crosses the page boundary, a formula in the merged cell that involves cells not on the current page only calculates using the cells on the same page as the merged cell. Steps to Reproduce: 1. Insert a new line. (Not part of the bug, just helps demonstrate it later on.) 2. Create a table with 2 columns and 100 rows. 3. Insert the number 1 into every cell of the first column. 4. Merge all of the cells in the second column into a single cell (e.g., select the entire column and hit F4 or right-click | Merge cells). 5. In the merged cell, insert the formula =SUM(<A1:A100>). 6. Notice that 50 is displayed. 7. Above the table, insert another new line (i.e., force another row to the following page). 8. Recalculate the table. Notice that 49 is displayed. Actual Results: Only the cells on the current page are included in the calculation. Expected Results: All cells in the specified range should be included in the calculation. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Please attach a sample file.
Created attachment 191781 [details] Requested attachment Here is the requested attachment. I generated it following precisely the instructions I provided in the bug report, in case anyone wishes to reproduce it from scratch. The bug is obvious from when the document is opened, and can be seen by inserting additional new lines above the table and recalculating the table.
The sum uses only two rows of the next page. Reproducible: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Also with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5056da285da2f130d741add1f8432cd590116a96 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Hi @Miklos, could be in relation with your work on floating tables?
Reproduced with sample document, starting at step 7, in recent trunk build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5056da285da2f130d741add1f8432cd590116a96 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded ...and in 7.3.7.2 as well. In 7.2.0.4, value would go to the correct 100 when using Tools > Update > Update all. Bibisected with linux-64-7.3 repository to first bad build [4a2fbf050faa2e4417e2067dad096613b4ac8c94] which points to: commit 01807ad5e04966abeb396b7599cbbbf822de6a03 author Luboš Luňák Fri Oct 01 12:30:15 2021 +0200 committer Luboš Luňák Sat Oct 02 00:36:00 2021 +0200 fix SwRect::Union() with empty SwRect Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122914 Luboš is not active anymore, so increasing the priority.