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: 2023-08-24 03:14 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

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 [retired] 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 Comment hidden (obsolete)
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 Comment hidden (obsolete)
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 Comment hidden (obsolete)
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
Comment 10 QA Administrators 2023-08-24 03:14:29 UTC
Dear Mike Kaganski,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team