I have a table with outside borders that has a header, a line for object[i] and another line for object[i+1]. The bottom border does not appear when I don’t have the row for object[i+1].
macos 13.3
LibreOffice 7.6
Example_report.odt (51.4 KB)
Please edit your question (=modify it, don’t unse a comment) and tag.
Which “component” are you using: Writer, Calc, Impress ? (you tagged common which means the problem occurs in all components) And retag accordingly.
Which is your OS? LO version? Document save format?
Since your screenshot doesn’t show any useful information, attach a sample document for analysis (1 page max.).
No problem with me. I tested with:
Version: 7.5.8.2 (x86) / LibreOffice Community
Build ID: f718d63693263970429a68f568db6046aaa9df01
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: es-MX (es_MX); UI: en-US
Calc: threaded
Version: 7.6.2.1 (x86) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: es-MX (es_MX); UI: es-ES
Calc: threaded
Here Fedora 38 (Linux), KDE Plasma desktop, LO 7.5.7.1; Nunito font used by your document not installed, consequently a substitution is used.
I experience the same issue as yours but it is easily explained: this occurs at bottom of page when the table spills over to next page. Writer sees that the table continues on next page and consider the bottom separator as one internal to the table (not the outise border) and draws it as an internal separator (none because you didn’t define one).
On next page, Writer is aware that the table is begun anew and draws an external separator (border) at top of table.
If the table is not split by a page break, everything is OK as reported by @LeroyG.
This can be considered as a bug. I don’t remember if it has already been reported (I think so but not sure).
If you see the misbehaviour in a context different from page break, just tell.
PS: your whole file is direct-formatted which will make tuning its layout and formatting very difficult. Learn to work with styles. One of the worst decisions of yours is to use drawing objects to put a horizontal line below some headings. It would have been much better and efficient to define a bottom border for these paragraphs (preferentially in their common paragraph style).
Hi,
Yes, I still find this issue in a context different from page break.
Could you describe what I should read in your attached file? I see “{d.primaryFinding[i]:variantType…}” which seems to be a “field” to be replaced by contents by some tool. But no replacement occurs on my computer because I have not the required tool.
The last row of the table contains “{d.primaryFinding[i+1]}” which is probably incomplete if I compare to the other cells where a dot follows the closing square bracket, then something like a directive (variantType, svLengthDescription, svTypeFullName, hgvsp, …). The three other cells in the last row are empty.
Your mysterious tool has probably hidden the last row without telling Writer. Then for Writer, the row above is not considered as the last one and the border is not displayed.
What is this tool?
It looks like a bug, unless it is a graphics rendering issue.
On Windows, I get the outside border in both normal view and print preview.
Where the table is split over the page I get a fake outside border at the bottom of the preceding page and at the top of the following page as described in tdf#82684
I use it with carbone.io to create reports. I solved this issue by adding an empty row so that I always have the bottom border.
Instead of using a third party tool (“universal” add-ons frequently have difficulties to integrate perfectly with “display” apps like Word or Writer because they don’t dig into the details of every suite), have you considered the report generator which comes with Base, the database front-end? Your data can come from a real fatabase, a spreadsheet or CSV text file. The report can be tuned graphically which makes it easy for beginners. Since it is a part of LO, you won’t experience the kind of problem you describe.