Bug 165032 - Writer's table boundary lines not displayed correctly in page-split row of the table
Summary: Writer's table boundary lines not displayed correctly in page-split row of th...
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks:
 
Reported: 2025-02-04 09:31 UTC by Orwel
Modified: 2025-02-19 21:15 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
test file (20.06 KB, application/vnd.oasis.opendocument.text)
2025-02-04 09:32 UTC, Orwel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Orwel 2025-02-04 09:31:57 UTC
Description:
Writer's table can be used for example for a 2-language document (English/German), where in the left table is text written in first language and in the right table in the other language.
If you use border-lines and a row of the table is split into 2 pages, the layout does not show that this is just one row, but it seems there are two rows.
Example in attached file.

Steps to Reproduce:
1. Insert a table (2x2)
2. Set line borders 
3. Press ENTER again to go to the next page.

Actual Results:
At the end of the page 1 is a bottom line and at the page 2 is a top line, although it is still one row.

Expected Results:
In my opinion this scenario should show these 2 lines so that it is clear, it is the same line. Suggested visualization in attached file.


Reproducible: Always


User Profile Reset: No

Additional Info:
As I am not sure if this is intended behaviour (then this should be treated as an enhancement) or a bug, I leave it as a bug, feel free to change it.
Comment 1 Orwel 2025-02-04 09:32:30 UTC
Created attachment 198963 [details]
test file
Comment 2 m_a_riosv 2025-02-05 21:42:53 UTC
Reproducible
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d723103ff8404ddadb3314dd3b67439602799d6c
CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

Let's ask UX for advice.
Comment 3 Heiko Tietze 2025-02-17 08:23:02 UTC
(In reply to Orwel from comment #0)
> Steps to Reproduce:
> 1. Insert a table (2x2)
> 2. Set line borders 
> 3. Press ENTER again to go to the next page.
Please be more specific. It makes a difference whether you click the toolbar button or use the dialog. Neither makes enter advance to the next page.

I vaguely remember that only one side takes the line style for performance reasons. But cannot find the respective ticket/discussion nor how to reproduce. But if that's the reason you may try to explicitly set left and right border.
Comment 4 Orwel 2025-02-17 22:36:31 UTC
(In reply to Heiko Tietze from comment #3)
> Please be more specific. It makes a difference whether you click the toolbar
> button or use the dialog. Neither makes enter advance to the next page.
> 
> I vaguely remember that only one side takes the line style for performance
> reasons. But cannot find the respective ticket/discussion nor how to
> reproduce. But if that's the reason you may try to explicitly set left and
> right border.
I do not understand which step is not clear - do you mean step 3? If you follow my steps on an empty file (the borders of the table are set automatically, you do not need to create them) and write a lot of text in the cell 1x1 (instead of writing text I have used pressing ENTER) until you reach next page, you will see the borders are not draw correctly - see page 1 on my attached file. Proposed visualization is on page 2 of my test file.
To make it more clear: if you have a table 1x2 and you write so much text in the cell 1x1 that you reach page 2, you will see, the table seems like 2x2 and not 1x2.
Comment 5 Heiko Tietze 2025-02-18 09:10:30 UTC
Missed the attached file. The table contains a paragraph that make the cell advance into the next page - and you expect a bottom line where the table ends. Would be misleading in many scenarios, though. Miklos what do you think?
Comment 6 Miklos Vajna 2025-02-18 13:10:32 UTC
I guess you could argue either way, but both Word and Writer render these cell borders on page split (and browsers don't do such a thing on printing). So best to not change that -- you would have to keep the old mode around anyway to keep compatibility with existing documents.
Comment 7 Heiko Tietze 2025-02-18 16:21:51 UTC
(In reply to Miklos Vajna from comment #6)
> So best to not change that -- you would have to keep the old mode around
> anyway to keep compatibility with existing documents.
How about a table boundary but with dashed line style? Wouldn't be shown on the printout and could help to understand... what exactly? Orwel, can you agree with WF?
Comment 8 Miklos Vajna 2025-02-19 08:08:01 UTC
I guess this is not black & white. :-) I would say the current behavior is not too bad and it's consistent with other office suites, so changing that would be a step back in my subjective opinion. But sure, it's always possible to add one more per-doc option, keep the current behavior unchanged for Word formats and then you can do something creative for the rest. Certainly just saying "won't fix" is easier.
Comment 9 Orwel 2025-02-19 21:10:41 UTC
Thanks for addressing this issue. I'm not very familiar with other suites, I mainly use LO, and as I sometimes use a table to create bilingual documents, where each row corresponds to a paragraph and the left cell is one language and the right cell is the other, this behaviour of the border at the end of a page, even though the cell continues, is sometimes confusing, mainly if the left "cell" on the next page is empty. But I understand if you do not want to change it. A dotted/dashed line would certainly be better than nothing for me :)
Comment 10 Orwel 2025-02-19 21:15:45 UTC
...and it should also be mentioned - even printing and exporting to PDF will make a line on the bottom of the page, although it is the same cell/row.