Created attachment 92634 [details]
Shows how merged Cell across multiple rows gets broken across a page-break
When a table has merged rows, it does not respect the “Do NOT break row across page breaks” setting.
When some cells from multiple rows are merged, its very purpose is to show the data in these rows together, as an unbroken picture. But this intent is defeated when the merged cells are broken across page-breaks.
Desired: the "Allow rows to break across pages and columns" setting is unchecked (which means splitting of the row is NOT allowed), and if such a table has cells from multiple rows merged together, then all such rows should be treated as a single row.
reproducible with LO 220.127.116.11 (Win 8.1)
Steps to Reproduce:
1. Open WRITER
2. Go to TABLE -> INSERT -> TABLE
3. Let the columns at 2 and increase the numbers of rows for instance to 10 and press INSERT to insert the table
4. Write any little longer text into the rows of the first column so that the table goes over at least two pages
5. Go to TABLE -> TABLE PROPERTIES -> tab TEXT FLOW
6. Deselect "Allow row to brake across pages and columns"
No row does break across pages.
7. Select two cells in the first column with the text (the last of page 1 and the first of page 2)
8. Make a right mouse click and go to CELL -> MERGE
Row crosses two pages despite the table properties.
Using Andy's example, what you'll find is that part of the merged cell (A7) that is adjacent to the first cell in the other column (B7) either stays on the first page or moves onto the second when empty paragraphs are added before the table. B7 and B8 want to respect the setting regardless of A7.
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Still reproducible on LibreOffice 18.104.22.168 (Windows 7)
*** Bug 61128 has been marked as a duplicate of this bug. ***
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still reproducible in 6.3.0, using the attachment from comment 1.
Version: 22.214.171.124 (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU tråde: 4; Styresystem: Windows 10.0; Gengiver af brugergrænseflade: GL; VCL: win;
Lokalisering: da-DK (da_DK); Sprog for brugergrænseflade: da-DK