Bug 72032 - FORMATTING: Vertically merged cells in TABLE are distorted
Summary: FORMATTING: Vertically merged cells in TABLE are distorted
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
Reported: 2013-11-26 13:10 UTC by Mike Kaganski
Modified: 2021-08-23 10:32 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:

Problem showcase (104.38 KB, application/x-zip-compressed)
2013-11-26 13:10 UTC, Mike Kaganski

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2013-11-26 13:10:38 UTC
Created attachment 89835 [details]
Problem showcase

Under certain conditions, the vertically merged cells of a table are distorted.

Steps to reproduce (the easiest I found, and giving me 100% reproducibility):
1. Create an empty text document in Writer using default template (I know that 4.2 will include a different default template than 4.1.x, so steps may be different for later versions).
2. Insert a new table having 2 columns and 9 rows.
3. In the table, merge each 3 cells in the first column (1+2+3, 4+5+6, 7+8+9).
4. Insert 48 empty lines (paragraphs) before the table, so that the table is split across the first and second pages.

Expected result: the table should be normal.

Actual result: the last row of the table is distorted: the first column looks like only two cells are merged (7+8), and the  ninth cell disappears (even if Table->Table Boundaries is turned on, there are no borders in the place where 9th cell must be).

If saved and reopened, the table shows correctly, but deleting and then inserting again one of the empty paragraphs before the table brings the problem back.

The distortion is not a visual artifact; it is printed and exported to PDF etc.
It is not bound to the last row only; sometimes cells in the middle are affected.
It is not always evident that this problem is related to the data before the table; I had to recreate my complex tables many times thinking that I broke them somehow, just to see another distorted cell. And it's not always possible to get rid of the problem just changing previous lines, especially with complex and long tables splitting over many pages, because distortion just moves from one cell to another.

Tested with, 3.4.6rc2, 3.5.7rc2,, and AOO4.0 under Win7x64 - all affected. Marking as Inherited from OOo.

Attached are the test document, the PDF and the screenshot of the problem. Note that the test odt will initially open fine; to see the problem, one must remove and then add one empty paragraph before the table.
Comment 1 Thomas van der Meulen 2013-11-26 14:06:35 UTC
Thank you for your bug report, I can reproduce this bug running 
Build ID: f4ca7b35f580827ad2c69ea6d29f7c9b48ebbac7
OS: Mac osx 10.9.
Comment 2 QA Administrators 2015-04-19 03:20:57 UTC Comment hidden (obsolete)
Comment 3 Mike Kaganski 2015-04-19 05:22:23 UTC
Still reproducible with Version:
Build ID: b2f347f2ac68821efc00b6f1793cda90af748118
Locale: ru_RU
under Win7x64
Comment 4 QA Administrators 2016-09-20 09:24:28 UTC Comment hidden (obsolete)
Comment 5 Mike Kaganski 2016-09-20 15:27:42 UTC
Still reproducible with (x64)
Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d
Comment 6 Telesto 2017-04-23 18:20:31 UTC
Still reproducible with version:
Build ID: 4354f0e9ef4a5538729a2a6f2d1745e247f6c5cd
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-04-21_06:05:57
Comment 7 QA Administrators 2018-04-24 02:32:47 UTC Comment hidden (obsolete)
Comment 8 Timur 2019-09-05 14:02:20 UTC
Repro 6.4+
Comment 9 BogdanB 2021-08-23 10:32:56 UTC
REPRO in Version: / LibreOffice Community
Build ID: 5b025285b3528910a4360899abb2bbbaadc72c97
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded