Bug 128421 - TABLE: Don't draw the top and bottom border of the row that breaks across pages
Summary: TABLE: Don't draw the top and bottom border of the row that breaks across pages
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 82684 104188 (view as bug list)
Depends on:
Blocks: Table-Borders
  Show dependency treegraph
 
Reported: 2019-10-27 22:43 UTC by John
Modified: 2023-11-15 22:52 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
test document (11.36 KB, application/vnd.oasis.opendocument.text)
2019-10-27 22:45 UTC, John
Details
screenshot of the issue (20.90 KB, image/png)
2019-10-27 22:46 UTC, John
Details
table border comparison linux vs win (1.11 MB, image/jpeg)
2023-02-13 11:36 UTC, flint
Details
table border comparison linux vs win (2) (1.10 MB, image/jpeg)
2023-02-13 11:53 UTC, flint
Details
comparison MS-Office<>LibreOffice (593.50 KB, image/png)
2023-03-15 17:57 UTC, flint
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2019-10-27 22:43:53 UTC
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:
Comment 1 John 2019-10-27 22:45:28 UTC
Created attachment 155353 [details]
test document
Comment 2 John 2019-10-27 22:46:14 UTC
Created attachment 155354 [details]
screenshot of the issue
Comment 3 Dieter 2019-11-05 15:25:43 UTC
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.
Comment 4 John 2019-11-05 16:57:25 UTC
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.
Comment 5 Dieter 2019-11-05 17:27:58 UTC
(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.
Comment 6 Heiko Tietze 2019-11-06 11:06:25 UTC
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...
Comment 7 John 2019-11-06 12:09:11 UTC
> 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...
Comment 8 Heiko Tietze 2019-11-06 16:23:57 UTC
(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?
Comment 9 Miklos Vajna 2019-11-06 16:40:21 UTC
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.
Comment 10 Miklos Vajna 2019-11-06 16:41:09 UTC
Not optimal, optional, sorry.
Comment 11 csongor 2019-11-12 13:46:07 UTC
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.
Comment 12 Heiko Tietze 2019-11-14 13:47:34 UTC
So let's do it.
Comment 13 ajlittoz 2022-11-21 10:17:52 UTC
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.
Comment 14 flint 2022-11-21 13:36:06 UTC
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.
Comment 15 flint 2023-02-13 11:36:50 UTC
Created attachment 185344 [details]
table border comparison linux vs win
Comment 16 flint 2023-02-13 11:40:00 UTC
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.
Comment 17 flint 2023-02-13 11:53:29 UTC
Created attachment 185345 [details]
table border comparison linux vs win (2)
Comment 18 flint 2023-03-15 17:56:01 UTC
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:
Comment 19 flint 2023-03-15 17:57:24 UTC
Created attachment 185986 [details]
comparison MS-Office<>LibreOffice
Comment 20 Stéphane Guillou (stragu) 2023-11-15 14:06:33 UTC
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.
Comment 21 Stéphane Guillou (stragu) 2023-11-15 14:07:39 UTC
*** Bug 82684 has been marked as a duplicate of this bug. ***
Comment 22 Stéphane Guillou (stragu) 2023-11-15 14:09:00 UTC
*** Bug 104188 has been marked as a duplicate of this bug. ***