1. Create a table with 3 rows and 2 columns. 2. Keep it clean but we'll virtually name the cells: --------- | 1 | 2 | --------- | 3 | 4 | --------- | 5 | 6 | --------- 3. Merge cells "3" and "5". 4. Got the test case file. 5. Merge the cells "2" and "4". 6. Expected: 3 rows. 7. Actual: 2 rows: --------- | | | --------- | | | ---------
Created attachment 192458 [details] Test case file
Reproduced in: Version: 7.5.9.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU Gentoo official package Calc: threaded
reproducible with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f289fe3dca487c45417f7b40d51a4830f3369fb1 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo and Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) Not sure if it's a bug, leaving unconfirmed.
Works fine for me with Version: 7.5.9.2 (X86_64) / LibreOffice Community Build ID: cdeefe45c17511d326101eed8008ac4092f278a9 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded Version: 7.5.9.2 (X86_64) / LibreOffice Community Build ID: cdeefe45c17511d326101eed8008ac4092f278a9 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded Version: 7.6.5.0.0+ (X86_64) / LibreOffice Community Build ID: 2e65401cf50ca25e16a0f3d4b624e2b48c97644c 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 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Maybe only Linux issue.
Created attachment 192468 [details] Screenshot of the merged cells This seems to be working fine for me in Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 4:7.6.4-0ubuntu0.23.10.1 Calc: threaded I'm getting the result I would expect. See attached image.
(In reply to Rafael Lima from comment #5) > Created attachment 192468 [details] > Screenshot of the merged cells > > This seems to be working fine for me in > > Version: 7.6.4.1 (X86_64) / LibreOffice Community > Build ID: 60(Build:1) > CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) > Locale: pt-BR (pt_BR.UTF-8); UI: en-US > Ubuntu package version: 4:7.6.4-0ubuntu0.23.10.1 > Calc: threaded > > I'm getting the result I would expect. See attached image. Exactly. Now, do the same *don't* fill the cells out: > 2. Keep it clean
Created attachment 192470 [details] Screenshot - before merge
Created attachment 192471 [details] Screenshot
I'm able repro Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded also in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 OpenOffice 2.2.0 doesn't the merge as described here --- It does work as reporter describes in MS Word/ Apple Pages. I have tendency to call it a bug
Same in OOo 3.3 -> inherited. The same process in the column direction does work as expected, but that likely is because the width of the table is fixed, and therefore does not collapse to the minimal space needed for the table cell contents like rows do. Adding contents to the cells eventually makes the cells increase their height, and shows that the border does not have to align between columns -> as expected. The issue could be circumvented by not collapsing the two empty paragraphs to a single on, but the issue remains that if cell contents are removed, we can always go back to what looks like a simple 2×2 table. And users likely don't want to end up with e.g, 10 empty paragraphs when merging 10 cells as one. So my take is "not a bug".
So, is there special code that collapse the right column's cells on collapsing the left column's cells?
Created attachment 192768 [details] sample ODT with 3 cases OK, I thought there was no bug if one thought of it as "automatic row height is only adapting to the (lack of) contents. However, there is an inconsistency that is made obvious by changing the row height. Try this: 1) Repeat the steps with a table with row 1 height increased by hand. Result: still collapses in the same way. 2) Repeat the steps with a table with row 2 increased by hand. Result: does not collapse. Marking as new, although I'm not sure which way it should be solved (is table 1/2 behaviour preferred, or table 3?). Attachment makes it easier to test the 2 different cases.
Table cells don't have an individual height in Writer. It follows the paragraph height - and the full row height. If the cell contains merged cells table:number-rows-spanned="2", content with multiple paragraphs or some larger spacing will affect only this cell (which is otherwise collapsed to the row height). I see no need to enhance the format / clutter the UI with cell height/width data. The issue seems to be very hypothetical. Regina, please correct if I'm wrong.
The current behavior is an unexpected result for the user. Therefore I consider it a bug, even it might be technical correct. I think, the problem is the attribute style:min-row-height. That is influenced by the field value from menu Table > Size > Row Height. The default field value there should not be zero as it is now. It should have as default the same value as will be set when you use "Optimal Row Height" on the empty table.
Hm, what does the "Row Height" field mean once "Optimal Row Height" is checked?
(In reply to Alexander Kurakin from comment #15) > Hm, what does the "Row Height" field mean once "Optimal Row Height" is > checked? It is the minimal row height. If you use "Optimal Row Height" for an empty table, the value in the field will differ from zero and therefore the empty table will look as expected. If the checkbox "Fit to size" is still selected, the row height will increase and decrease with the content as expected. But it will only decrease to this minimal row height value and not decrease to zero height.
Whether the minimum row height is zero or takes some value from the paragraph style doesn't matter for the question what height a single cell has. The perceived issue here is that merged cells don't span over multiple rows when empty. And I think this is not a bug neither can be fixed without bringing cell height attributes into the format. Which in my opinion is not needed.