See the test case file and the screenshot.
Created attachment 187520 [details] Test case file
Created attachment 187521 [details] Screenshot
Reproduced in: Version: 7.4.6.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU Gentoo official package Calc: threaded
REPRODUCIBLE with reporter's sample document and installation of Version: 7.5.3.2 (X86_64), Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE | Elementary Theme | My normal User Profile | Calc: threaded But I failed to create an own table, because I havent a clue what a "Vertical Whitespace" might be here. @reporter: please contribute a step by step construction instruction for such a table.
> please contribute a step by step construction instruction for such a table. Sorry no, cause this test case is just a part of the big document.
(In reply to Alexander Kurakin from comment #5) > Sorry no, cause this test case is just a part of the big document. But it should be possible to give some information about the steps to create such a table.
(In reply to Dieter from comment #6) > (In reply to Alexander Kurakin from comment #5) > > Sorry no, cause this test case is just a part of the big document. > > But it should be possible to give some information about the steps to create > such a table. Ok, I got the minimal example and the instruction: 1. Open the Writer. 2. Press <Ennter>. 3. Open "Table" -> "Insert Table". 4. Set "Columns" to "2". 5. Set "Rows" to "4". 5. Click "OK". 6. Select 2nd, 3rd, 4th rows of the 1st column. 7. Click "Table" -> "Merge cells". 8. Move at the merged cell. 9. Type "1 2 3 4". 10. Move the table by adding new lines before it: "1\n2" text is at the 1st page, "3\n4" text is at the 2nd page. 11. Everything is as expected now: |-----|-----| | 1 | | | |-----| | 2 | | | |-----| <-- PAGE BREAK --> | 3 | | | |-----| | 4 | | |-----|-----| (There are *no* gaps at the 1st column.) 12. Select the table. 13. Set "Center Vertically" option. 14-a. Result: the Test Case Document - 2. 14-b. Expected: (almost) nothing changed visualy. 14-c. Actual: see the Screenshot - 2. (For loosing of background, see the original Test Case Document as I can't reproduce.)
Created attachment 187790 [details] Test case document - 2
Created attachment 187791 [details] Screenshot - 2
Thank you for reporting the bug. I can confirm that the bug is also present in earlier version Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded However, the bug disappeared in this version Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Thank you for reporting the bug. There are 2 parts that I could update on this issue: 1. Background color issue: - I can confirm that the bug is also present in earlier version Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded - However, the bug disappeared in this version Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded 2. Vertical whitespace gap I can confirm that the bug is also present in earlier version Version 3.6.7.2 (Build ID: e183d5b)
This is the result of the bi-bisection of the background bug (my hardware is Windows 10), but the bug is also visible on Windows and LO7.2, but not with LO7.1: source 1001dbaef4dec2b51c25ed8343bab6910f1219e1
There are two problems here: 1) the strange vertical whitespace gap and 2) the wrong background. The second problem started with the commit mentioned in comment 12, so let's focus on that problem for the scope of this bug. The first problem is already there right before the above commit. Most probably you'll need a separate bug for the first problem, so we can evaluate if that's a regression as well, bisect, etc. I'll take a look at the second half.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7c15750cecea2aeb05653c0ee67b933d969b1f0b tdf#155510 ODT import: ignore props of covered table cells, unless in comp mode It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/7ed4404a38b477bdec9c1eb463fc216dc025a881 tdf#155510 ODT import: ignore props of covered table cells, unless in comp mode It will be available in 7.6.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Miklos Vajna from comment #13) > Most probably you'll need a separate bug for the first problem, so we can > evaluate if that's a regression as well, bisect, etc. Done in bug #156966 .