Description: When cells are merged that span pages using centered or bottom alignment, the text is not displayed correctly according to the selected alignment, and is not properly updated when the merged cell appears on a single page after having spanned multiple pages. Steps to Reproduce: 1. Insert a new line. (This is not part of the bug, but makes some of the following steps easier to follow.) 2. Insert a table with 2 columns and 75 rows (enough to span two pages). 3. To make seeing the bug easier, I recommend Multipage View and reducing the zoom so that two pages are visible at once. 4. Select all of the cells in the second column that are visible on the first page. Merge them (F4 or Right-click | Merge). 5. Enter the merged cell and type "hello." 6. Select all of the cells in the second column that are visible on the second page. Merge them (F4 or Right-click | Merge). 7. Enter the newly merged cell (now the second one in the second column) and type "Goodbye." 8. Select the entire table. Go to Table Properties | Text Flow | Vertical Alignment and set it to Bottom. Hit OK. Notice that Hello and Goodbye are now at the bottom of their cells. 9. Go to the new line before the table. Hit return. Notice that the word "Hello" jumps to the top of the merged cell. Instead, it should be displayed at the bottom of the merged cell which is now at the top of page 2. 10. Select the entire table. Go to Table Properties | Text Flow | Vertical Alignment and set it to Top. Hit OK. Notice that both Hello and Goodbye appear at the top of their cells. 11. Select the entire table. Go to Table Properties | Text Flow | Vertical Alignment and set it to Bottom. Hit OK. Notice that Hello is incorrectly displayed at the bottom of the merged cell on page 1, NOT at the true bottom of the merged cell, which is on the top of page 2. 12. Go to one of the new lines above the table, and delete one of them. The merged cell should now be entirely displayed on page 1. Notice that Hello jumps back to the top of the merged cell rather than staying at the bottom as it should. 13. All of these steps can be repeated with Center vertical alignment as well, and the same problems occur: when the merged cell spans to the second page, the text jumps to the top; when the Table is set to Top and then to Center, forcing a recalculation, the vertical center is calculated relative to the amount of the merged cell displayed on page 1, rather than with respect to the full height of the merged cell, including the part which spans onto the second page. And when the merged cell is returned to appear on a single page, the center is not recalculated unless the vertical alignment is changed to something else and then back to Center. Actual Results: Text jumps to the top when the merged cell changes its span from one page to two or back from two to one. When the merged cell spans two pages, bottom and center alignments are calculated only relative to the amount of the merged cell displayed on the first page rather than the entire height of the merged cell, including the part displayed on the second page. Expected Results: The position of text in cells with center and bottom alignments should be calculated with respect to the entire height of the merged cell even when it spans two pages, and remain constant whether the cell is on one page or spans two pages. 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
(In reply to William Friedman from comment #0) > Description: > When cells are merged that span pages using centered or bottom alignment, > the text is not displayed correctly according to the selected alignment, and > is not properly updated when the merged cell appears on a single page after > having spanned multiple pages. > > Steps to Reproduce: > 1. Insert a new line. (This is not part of the bug, but makes some of the > following steps easier to follow.) > 2. Insert a table with 2 columns and 75 rows (enough to span two pages). > 3. To make seeing the bug easier, I recommend Multipage View and reducing > the zoom so that two pages are visible at once. > 4. Select all of the cells in the second column that are visible on the > first page. Merge them (F4 or Right-click | Merge). > 5. Enter the merged cell and type "hello." > 6. Select all of the cells in the second column that are visible on the > second page. Merge them (F4 or Right-click | Merge). For me, the merged cells collapse at this step, so the table only takes a bit over half a page. Therefore, I am not able to reproduce in a meaningful way. The collapsing happens even, if I have merged only a few cells. Same on Windows and Linux. Arch Linux 64-bit, X11 Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.6.4-2 Calc: threaded
Created attachment 192068 [details] sample ODT to start at step 11 Attachment allows reproducing starting at step 11. (In reply to William Friedman from comment #0) > 11. Select the entire table. Go to Table Properties | Text Flow | Vertical > Alignment and set it to Bottom. Hit OK. Notice that Hello is incorrectly > displayed at the bottom of the merged cell on page 1, NOT at the true bottom > of the merged cell, which is on the top of page 2. Reproduced > 12. Go to one of the new lines above the table, and delete one of them. The > merged cell should now be entirely displayed on page 1. Notice that Hello > jumps back to the top of the merged cell rather than staying at the bottom > as it should. Reproduced Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8b393bba91111bd4f8988457f3a78b0306462bf2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded In OOo 3.3 however, at step 12: text stays at bottom of cell. So step 11 is inherited, and step 12 is a regression. Focusing on the regression, I note that: - in 7.2.0.4, clicking inside the table "refreshes" the alignment and brings the text back to the bottom (not ideal, but better than current) - in 7.3.7.2, the text remains at the top even when interacting with the table. Bibisected with linux-64-7.3 repo to first bad build [4bdbd7dd9dc55e0b0ada3a62a8de68a78811a5e2] which points to core commit dadaf930d14283f96cc06741d2eec6d846e59f7f which is a cherrypick of: commit c605283ad6785dea762feab5fdffd9d27e75c292 author Michael Stahl Mon Jul 11 19:20:33 2022 +0200 committer Michael Stahl Wed Jul 13 16:58:05 2022 +0200 sw: fix spurious layout invalidation from ~SwCallLink() Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136963
Michael, can you please have a look at the regression? Other, pre-existing issues mentioned here can be tracked separately if needed.
Stephane, I was about to upload a test document, so thank you for saving me the time. I was playing around with your document, and noticed a new wrinkle. To make this less wordy, I'm going to use "hello" to refer to the top merged cell and "goodbye" to refer to the bottom merged cell. After step 12: 13. Delete the last remaining line before the table. This causes the "goodbye" cell to span onto the first page. "Hello" jumps to the bottom of the column (correctly!), while "goodbye" jumps to the top (incorrectly). 14. Hit ctrl-Z or insert a new line before the table. Now both "hello" and "goodbye" are fully on their own pagess. "Hello" stays the bottom (correctly!), and "goodbye" jumps back to the bottom (correctly!). 15. Insert another new line before the table. "Hello" now spans two pages, and its text jumps back to the top. "Goodbye" remains correctly bottom-aligned. 16. Hit ctrl-Z. Despite the fact that "hello" is now back on one page, its text remains stuck at the top. "Goodbye" remains correctly at the bottom. It seems from this that the bottom alignment of the top merged cell ("hello") is recalculated when the bottom merged cell ("goodbye") starts to appear on the first page, but *not* when the top merged cell stops spanning two pages. Once the bottom alignment is recalculated, though it "sticks" until the merged cell spans two pages again. But, interestingly, the bottom merged cell ("goodbye") *does* recalculate correctly *immediately after* it stops spanning two pages, which does not happen immediately when the top merged cell stops spanning two pages.