Description: 1. Create a table with 2 columns and 6 rows. 2. Add dummy data in each cell of the first column: Cell 1: a1, a2, a3, a4, a5, a6, a7, a8, a9 Each "a" should be on it's own line. Cell 2: b1, b2, ... And so on. See the attached document. 3. Notice that F row breaks across pages. 4. Notice that F row looks like 2 separate rows. Attached files: * borders.odt * borders.png Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 155353 [details] test document
Created attachment 155354 [details] screenshot of the issue
I confirm the observed behaviour. But I won't expect that the row is left open. As far I remember standard in literature is zig-zag line. But LO doesn't provide it. Perhaps it would be an enhancement to add a dashed line, to mark, that a row breaks across pages. What do you think, John. cc: Design Team to make a decision.
Ziz-zag line, as I understand is used as a metaphor of torn paper. To my opinion: * Dashed line: Is not very good. It can be considered as a "real" border by some users. Aslo, some complex tables could have "real" dashed borders between some rows. And it will lead to confusing. * Ziz-zag line: Better than dashed line. However, for what reason we need? It is just a visual noise. Also, consider the case when we hide the whitespace between pages (menu bar > View > Hide Whitespace). Zig-zag lines will be stacked very close to each other. Ugly and distracting. This is also true for dashed lines. * No line: The best possible option. The most easy-to-understand and the most clear from visual point of view (i.e. doesn't add any unnecessary clutter). In case it is not technically possible to remove it, we can use the white color instead to make it invisible.
(In reply to John from comment #4) > * No line: The best possible option. The most easy-to-understand and the > most clear from visual point of view (i.e. doesn't add any unnecessary > clutter). In case it is not technically possible to remove it, we can use > the white color instead to make it invisible. I can't remember, that I've ever seen that.
How would you expect a table with inner border to be printed? With or without border at the row with a page break? It is, BTW, the same behavior as MSO Word has. WYSIWYG...
> How would you expect a table with inner border to be printed? With or without border at the row with a page break? I understand the words, but I don't understand the question itself...
(In reply to John from comment #7) > I understand the words, but I don't understand the question itself... Sorry, I've put two ideas in one sentence. First, the (inner) border needs to enabled to show up in the document. If you format the table without, there wouldn't be any problems. Second, the question is what you expect when you print the test document. Is the border at the bottom of the page visible or do you expect the same as requested here. And finally I mentioned that MSO does the same. We have to make sure the round trip (save to docx, load in different app, etc.) doesn't break the document. Could be done by formatting this particular cell border - but I see this as a major show stopper. Miklos, what's your opinion?
I consider it a benefit that Writer is consistent with Word here by default. If one wants to spend the effort to add an optimal mode to hide those borders, I don't mind, though don't have use case for it as is.
Not optimal, optional, sorry.
I can see the benefit of the requested feature. I think it should be a table attribute like this: [x] Draw top and bottom borders of cells that overflow through a page break The default should be ON, which is the current behaviour. Probably it needs an ODF change which makes it difficult. Thus, I am not saying we should do this, I am just saying that the request does make sense.
So let's do it.
The situation is not that simple and bottom and top separator appearance must be considered separately. No heading repetition: what appears at bottom and top of page is a row separator. In case of row split, no separator (selected by user) are shown. Their absence is a clear hint at row continuation. Heading repetition: - the separator at bottom of page can be suppressed to hint at row continuation across the page break - but the heading at top of next page is repeated Then we start with the horizontal outer border and the row is formatted as designed by user. By default, if there is no special border at bottom of heading, then this is a row separator. Since the heading is not part of the split row, a row separator must de drawn. Row continuation is only indicated by the absence of seprator at bottom of page.
Just wanted to let you know that the proposal of csongor@halmai.hu with the feature: "I think it should be a table attribute like this: [x] Draw top and bottom borders of cells that overflow through a page break" would be, in my opinion, absolutely perfect and very much appreciated if this could be implemented.
Created attachment 185344 [details] table border comparison linux vs win
Hi all, wanted to let you know that the described bug is handed differently in win10 and linux (openSuse), see picture (attachment). In Win10 there is no problem, in linux yes.
Created attachment 185345 [details] table border comparison linux vs win (2)
With the update of LibreOffice to 7.5.1.2 the above described issue is still available. Also the same table border settings are handed differently in LibreOffice and MS-Office. I did a comparison and you can see the difference in the attached picture:
Created attachment 185986 [details] comparison MS-Office<>LibreOffice
The issue was reported before in bug 82684, but as an enhancement request is discussed here as a solution, let's mark the older one as a duplicate.
*** Bug 82684 has been marked as a duplicate of this bug. ***
*** Bug 104188 has been marked as a duplicate of this bug. ***