Created attachment 190401 [details] Table border error can be easily seen. Even if only an external border for a table is selected, the borders will be formatted wrong. The problem is present even when exporting to PDF.
In my understanding the bug reported is, that the “outer border” formatting effects the borderlines within the table, when the table crosses over 2 pages. That is, what I tried to replicate. I replicated the bug with: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Steps to replicate: 1. Open empty document 2. Create a table via Table > Insert Table 3. In the wizard klick “Insert” →Now you have a 2x2 Table with two rows width 4. Enlarge the table over a pagebreak (I placed cursor inside and pressed enter repeatedly (see attachment 157911 [details]_0_Table_no_formatting.odt) 6.Right klick on the table → Table properties → Borders 7. A) Give a border to the left and the bottom line (see attached screenshot for an example), when your table breaks with the second row over the page B) Give a border to the left and the top line, when your table breaks with the first row over the page 8. Hit enter Expected result: The left and the bottom line are formatted according to the settings Actual result: The two lines + the middle line are formatted, see example file 2 It seems as it works as a page setting, instead of a table setting. And either colours the bottom of one page or the top of the next. If the cells are expanded to further pages, the behaviour stays coherent. In another test I used “Simple List shaded” - See file 157911_3_Table_3pages.odt: Here the table spans 3 pages and only on the third page are bottom and top horizontal line coloured. If you colour the top line, the top and bottom of the first page will be coloured. As my replication is not 100% accurate if I compare it with the OP's screenshot, where only a cell after the pagebreak looks wrongly formatted, I'd like to ask Nicola to provide the sample file.
Created attachment 190470 [details] Base File
Created attachment 190471 [details] Table over 3 pages
Created attachment 190472 [details] Settings Table
Created attachment 190473 [details] Table over 2 pages with the bug showing -> Follow up from Base File
Created attachment 190661 [details] Added 3 pages sample with reported bug for tables external border on multiple pages.
[Automated Action] NeedInfo-To-Unconfirmed
With attachment 190661 [details], reproduced as in screenshot attachment 190401 [details] in: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 31fb3045dabdb27d913712f3abcade315e3ea9bd CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded But not in 7.5: Version: 7.5.8.2 (X86_64) / LibreOffice Community Build ID: f718d63693263970429a68f568db6046aaa9df01 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded -> regression.
Bibisected with linux-64-7.6 repository to first bad commit >036b633c8ca62e0a10fe11bac53c97fc406e2bee which points to core commit e7c02ea29d92bed2d713b9a3180bfb1674add908 which is a cherrypick of: commit 08aea5526c75ff4c5385e960bd940f10ffa19cd5 author Miklos Vajna Mon Aug 21 08:33:14 2023 +0200 committer Miklos Vajna Mon Aug 21 09:36:32 2023 +0200 tdf#156351 sw floattable: fix missing bottom border in master table Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155884 Miklos, can you please have a look?
(In reply to Philipp from comment #1) > In my understanding the bug reported is, that the “outer border” formatting > effects the borderlines within the table, when the table crosses over 2 > pages. That is, what I tried to replicate. Thanks Philipp for attempting to clarify. What you described is not what Nicola sees, I just checked with the bibisected commit. So I'm marking your comments as "off topic" for the sake of clarity, but feel free to move your comments to a new report if you really think there is a bug :)
(In reply to Stéphane Guillou (stragu) from comment #9) > Miklos, can you please have a look? I'll take a look.
To be fair, I think the expected result is not trivial, so there is some value in discussing that, and that's what Philipp also tried to do, to some extent. :-) If I look at the split table on the page 1 -> page 2 boundary, then the bottom of page 1 has a bottom border only in the 1st column, while the entire page 2 top has a border. This suggests that it was correct to try to have an automatic bottom border at the end of page 1, just it has to go further, so it's fully symmetric with the top of page 2. The old case was that the split table had an implicit top border on page 2 and no implicit bottom border on page 1, I don't think we want to go back there, as it was inconsistent. (Or at least right now I don't see a reason to stick to such an inconsistent render result.) Thanks.
Created attachment 190814 [details] Comparison LO 24.2alpha0+, Office 365, OnlyOffice 7.5.0.127 Thanks Miklos. For what it's worth, the file saved as DOCX won't show a bottom or top border where the table is split in both online Office 365 and OnlyOffice. But regardless, I trust you to know what to do with those given you've spent quite a few weeks knee-deep in Writer tables :)
Aha, that's useful data, thanks Stéphane. The situation is tricky: - Word's border model is more rich, it has table-level, row-level and cell-level borders - Writer's border model is simplier, it only has cell-level borders - To be able to render the bug 156351 correctly, we need to infer some top/bottom borders - Word does this for table-level borders, but not for cell-level borders, but unfortunately in Writer these are all simplified to cell-level borders, so we don't really see the difference I think it's clear that the current state is poor, a half-border is worse than no border or a proper border with the size of the table width. I'm leaning towards the table-width border (rather than no border) as the majority of the documents contain table-level borders (i.e. I consider bug 156351 typical and this document's DOCX version somewhat rare), and historically Writer always did some inferring of these borders, the above commit just extended that to do it in more cases. Anyhow, I'll think it through and document the pros/cons in the commit message.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/47d824dd167eb34b08e5aec7141d2d9e6e996b34 tdf#157911 sw floattable: fix inconsistent inferred bottom border on split 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.
I fixed the inconsistent "half-border" by having a full border at page 1 end, that avoids the wrong border. It may make sense to have a follow-up enhancement bug for the deeper problem that I think Writer tables only have cell-level borders while Word also has table-level ones. You can see this limitation if you e.g. create a table of 2 rows, set an outer border, go to the last cell of the table, press "tab" to insert a new row, and then the outer border also happens at row 2 bottom, not only at the new row 3 bottom.
(In reply to Miklos Vajna from comment #16) > I fixed the inconsistent "half-border" by having a full border at page 1 > end, that avoids the wrong border. It may make sense to have a follow-up > enhancement bug for the deeper problem that I think Writer tables only have > cell-level borders while Word also has table-level ones. Thanks Miklos! The most relevant bug I found regarding that issue is bug 144255.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/7a1b3f58080b301929269c0b4a5310851a0ee2bb tdf#157911 sw floattable: fix inconsistent inferred bottom border on split It will be available in 7.6.4. 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.
Fix verified in: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 619500d6919c227e734b119481a4b334972e0b7b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Thank you Miklos!