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:
Depends on:
Blocks: Table-Borders
  Show dependency treegraph
 
Reported: 2019-10-27 22:43 UTC by John
Modified: 2019-11-27 09:54 UTC (History)
3 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

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.