Bug 170506 (TableFillBug001) - Table Cell / Row / Column Fill leaves "off-by-one" line on bottom edge
Summary: Table Cell / Row / Column Fill leaves "off-by-one" line on bottom edge
Status: NEW
Alias: TableFillBug001
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.8.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 170502 (view as bug list)
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2026-01-28 06:48 UTC by Nobody
Modified: 2026-01-31 01:05 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Libre Writer file showing issue (12.81 KB, application/vnd.oasis.opendocument.text)
2026-01-28 06:49 UTC, Nobody
Details
PNG image of the issue when opened as a PDF inside of an image editor. (104.26 KB, image/png)
2026-01-28 06:50 UTC, Nobody
Details
Modified file (12.91 KB, application/vnd.oasis.opendocument.text)
2026-01-28 22:24 UTC, m_a_riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nobody 2026-01-28 06:48:07 UTC
Description:
When a table is created, and the user fills the cells, rows or columns with a background color - the color does not fill the entire cell. It instead leaves a small white line on the bottom of the cell.

This white line is evident when the document is printed.
This white line is evident when the document is exported as a PDF, and opened in Photoshop or like programs.

Steps to Reproduce:
1. Create a table (preferably with large enough fonts)
2. Fill cells with background color
3. Zoom in, or out
4. Print document

Actual Results:
Cells that have applied a background fill color exhibit the issue.

Expected Results:
The fill tool should not exhibit a white space / line at the bottom of the cells affected.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 25.8.4.2 (X86_64)
Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df
CPU threads: 20; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: en-CA (en_US); UI: en-US
Calc: CL threaded
Comment 1 Nobody 2026-01-28 06:49:16 UTC
Created attachment 205214 [details]
Libre Writer file showing issue
Comment 2 Nobody 2026-01-28 06:50:05 UTC
Created attachment 205215 [details]
PNG image of the issue when opened as a PDF inside of an image editor.
Comment 3 Nobody 2026-01-28 07:26:29 UTC
*** Bug 170502 has been marked as a duplicate of this bug. ***
Comment 4 V Stuart Foote 2026-01-28 12:23:12 UTC
Confirmed

Seems to be an "off-by-one" between table cell area selection box and its applied fill. Exposed line showing bottom edge picks up the page color fill coming through, so it is not empty. Less noticeable with hairline or thin border width, more so with the extra thick border of sample doc.


Version: 25.8.4.2 (X86_64)
Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df
CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 5 m_a_riosv 2026-01-28 22:24:30 UTC
Created attachment 205243 [details]
Modified file

I think it happens, because there are borders defined.
Deleting the borders, solves the issue.
Comment 6 Nobody 2026-01-29 09:37:44 UTC
(In reply to m_a_riosv from comment #5)
> Created attachment 205243 [details]
> Modified file
> 
> I think it happens, because there are borders defined.
> Deleting the borders, solves the issue.

I looked at your file, the white line is still visible but very tiny.
Comment 7 m_a_riosv 2026-01-30 02:07:31 UTC
Have you disable Menu>View>Boundaries?
Comment 8 Nobody 2026-01-31 00:34:18 UTC
(In reply to m_a_riosv from comment #7)
> Have you disable Menu>View>Boundaries?

Disabling boundaries with borders set to NONE removes the hairline.
Comment 9 m_a_riosv 2026-01-31 00:56:58 UTC
So, not a bug.
Comment 10 V Stuart Foote 2026-01-31 01:05:00 UTC
Actually it is an actual issue. The width of the border should be correctly calculated --no off by one--, especially as the gap is passed through on export to bitmaps as noted in OP.

That it is not noticeable when border is closer to the hairline default, does not mean it is correct as the border weight increases.