Bug 76280 - FORMATTING: Upper table border is missing on subsequent pages/columns (after page / column breaks)
Summary: FORMATTING: Upper table border is missing on subsequent pages/columns (after ...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Table-Borders
  Show dependency tree / graph
 
Reported: 2014-03-17 17:14 UTC by Marc PHILIPPE
Modified: 2023-11-17 07:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
OpenDocument showing the same table in sections wih 1, 2 or 3 columns. (26.90 KB, application/vnd.oasis.opendocument.text)
2014-03-17 17:14 UTC, Marc PHILIPPE 		Details
Test document + preview (203.17 KB, application/zip)
2015-05-03 05:46 UTC, Marc PHILIPPE 		Details
ODT + PDF of the same document (17.06 KB, application/vnd.oasis.opendocument.text)
2015-05-14 17:39 UTC, Marc PHILIPPE 		Details
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marc PHILIPPE 2014-03-17 17:14:05 UTC 
Created attachment 95956 [details]
OpenDocument showing the same table in sections wih 1, 2 or 3 columns.

Problem description: 

Steps to reproduce:
1. Create a section with 2 columns (or more);
2. In that section, insert a table;
3. The table must have enough lines to be spread over several columns.

Current behavior:
From column 2, the upper table border is not drawn.

Expected behavior:
An upper border should be drawn on the top of each column.
              
Operating System: Windows 7
Version: 4.2.1.1 release
Comment 1 sophie 2014-03-18 16:46:27 UTC 
Confirmed using Version: 4.2.3.1
Build ID: 3d4fc3d9dbf8f4c0aeb61498a81f91c5b7922f13 Ubuntu 13.10 - Set as New, change OS to all - Sophie
Comment 2 Dominique Boutry 2014-03-27 08:04:18 UTC 
Tied with bug 70018, in my opinion.
Comment 3 Joel Madero 2015-05-02 15:41:54 UTC Comment hidden (obsolete)
Comment 4 Marc PHILIPPE 2015-05-03 05:44:23 UTC 
Still present in LO 4.4.2.2 on Windows 7
(Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6).

No change in bug behavior.

See attachment bug76280.zip.
Comment 5 Marc PHILIPPE 2015-05-03 05:46:42 UTC 
Created attachment 115280 [details]
Test document + preview
Comment 6 Marc PHILIPPE 2015-05-14 17:36:37 UTC 
I changed the bug summary, for the concerned behaviour shows up:
- if the table spans over several pages (newly mentioned here);
- if the table spans over the different columns of a multiple-column section.

See next attachment.
Comment 7 Marc PHILIPPE 2015-05-14 17:39:22 UTC 
Created attachment 115607 [details]
ODT + PDF of the same document
Comment 8 Cor Nouws 2016-05-18 07:30:41 UTC 
already a problem in LibreOffice 3.3.0
Comment 9 QA Administrators 2017-05-22 13:40:00 UTC Comment hidden (obsolete)
Comment 10 Cor Nouws 2017-08-13 20:37:09 UTC 
still not ok in Version: 6.0.0.0.alpha0+
Build ID: 368b583b992f2e9cad46c2362c9529a07c36d7a9
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-08-10_02:55:46
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 11 Regina Henschel 2017-08-14 00:18:12 UTC 
If you mark a single cell and look into the tab Border of the table properties, you will notice in the part "user-defined", that the cell has no upper border.  So the border you see between two adjacent cells belongs to the upper cell. If such cell is the first on a page or first in a column, it has no cell above and therefore there is no border.

So there exist two ways to correct the table:
(1) Mark the first cell of the page or column respectively and enable the upper - border line. If the page or column break is not yet fix, then you need to correct all cells. More generally, you should use an AutoFormat, where all cell borders are set.
(2) Go to tab Borders of the table properties and check "Merge adjacent line styles".

The option "Merge adjacent line styles" is checked as default in version: 6.0.0.0.alpha0+
Build ID: f1a896c71c495bdef5861eb664581507b6b9b5bb
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-08-13_07:38:19
Locale: de-DE (de_DE); Calc: group

I wonder, how and why the option "Merge adjacent line styles" becomes unchecked in the attached file.
Comment 12 QA Administrators 2018-08-15 02:33:22 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2021-02-02 03:51:07 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2023-02-03 03:22:27 UTC Comment hidden (obsolete)
Comment 15 Stéphane Guillou (stragu) 2023-11-17 07:20:06 UTC 
As Regina pointed out in comment 11, the sample document has tables with inner borders only using a bottom border, and without the option "Merge adjacent line styles" ticked. Therefore, it makes sense to have no border at the top of the row if there isn't another row right above.

Tested in a recent trunk build, a new table still uses no top border for inner rows, but "Merge adjacent line styles" is on by default (as Regina observed in 6.0). The option persists after a save + reload.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

The behaviour is the same in OOo 3.3.

So closing as "not a bug" as the table behaves according to its settings. (But if you have steps that reproduce a loss of the merge setting, or a mismatch with border preview, please do share.)