Bug 153388 - Calc UI: Incorrect rendering of cell borders
Summary: Calc UI: Incorrect rendering of cell borders
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.4.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Border
  Show dependency treegraph
 
Reported: 2023-02-05 07:35 UTC by David Lynch
Modified: 2023-08-25 07:39 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Exhibits bug 153388 (1.59 MB, application/vnd.oasis.opendocument.spreadsheet)
2023-02-05 07:38 UTC, David Lynch
Details
Exhibits bug more clearly (8.17 KB, application/vnd.oasis.opendocument.spreadsheet)
2023-02-06 20:37 UTC, David Lynch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Lynch 2023-02-05 07:35:16 UTC
Description:
In the attached spreadsheet:
Enter d in g.I6.
Observe cell border width between g.I22 and g.I23, it is wrong.
[+Page][-Page], the cell border width between g.I22 and g.I23 has changed: it is now correct.

Steps to Reproduce:
See description

Actual Results:
See description

Expected Results:
See description


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Same results in safe mode.
Not new in 7.5, noticed this several months ago.
Incorrect rendering affects only the penultimate border in a vertical direction of a border changed by a change in a parameter to STYLE().
Comment 1 David Lynch 2023-02-05 07:38:23 UTC
Created attachment 185128 [details]
Exhibits bug 153388
Comment 2 raal 2023-02-06 17:08:51 UTC
No repro with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b052ec2f2fbe0f3044ba824c064a280a5ee9cd7f
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

Can you attach screenshots?
Comment 3 ady 2023-02-06 19:05:05 UTC
I can see the subtle change with LO 7.4.4, but it is really dependent on exact situation, zoom, screen resolution... If I change zoom value, or hide part of the columns or rows, I might not see the difference. Or I might see it but slightly in a different way than the first time.

So, the steps to (kind of) "repro" this, at least for me, must be exactly as described:

1. Open attachment 185128 [details].
2. In cell I7 of sheet "g", type in "d" (without quotation marks).
3. Note the border between I22 and I23. It is slightly different than the others.
4. Page down, page up.
5. Note the border between I22 and I23. It looks different than before.

Now, I've tried additional things, using a 7.6 alpha+:

6. Zoom-in (400%) to I21. I can see that the border between I22 and I23 is different than between I23 and I24. The border between I22 and I23 looks similar to the border between H23 and I23.

Additional details:
A_ IDK what is the width of the border that was supposed to be expected in each case.
B_ IDK whether the borders that look wider than that between I22 – I23 are like that (wider) because of some border being set "twice", in both neighboring cells.
C_ IDK whether this is a LO issue, or an OS issue, or a screen resolution/zoom issue, or a graphic card issue, or…


The 7.6 alpha+ that I tested with is:
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d8e6b488ceaff7c88856ebcfcfec14d2d8cd7652
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL threaded

I'm not sure I can call this NEW (yet).
Comment 4 David Lynch 2023-02-06 20:33:10 UTC
I have loaded bug153388b which shows what happens more clearly:

Enter d in B1:
  The border between B9 and B10 is thinner that that between B8 and B9: this is wrong.
[+PAGE][-PAGE]:
  The border between B9 and B10 is the same as that between B8 and B9: this is right
Delete d in B1:
  There is a border between B9 and B10: this is wrong.
[+PAGE][-PAGE]:
  The border between B9 and B10 disappears: this is right.
Comment 5 David Lynch 2023-02-06 20:37:33 UTC
Created attachment 185160 [details]
Exhibits bug more clearly
Comment 6 ady 2023-02-07 02:40:12 UTC
Attachment 185160 [details] indeed shows the behavior more clearly.

It can also be seen when using Conditional Format in the same file:

1. Select cells F3:F9
2. Conditional Format
3. Formula is $B$1="d"
4. Apply style "bot"; OK.
5. Cell B1: d
6. Note the borders.
7. Scroll page down, scroll page up.
8. Note the borders.
9. Delete the content of cell B1.
10. Note the borders.
11. Scroll page down, scroll page up.
12. Note the borders.

The "bot" style seems to have borders in both, top and bottom borders. Since the strange rendering happens on the lowest of the formatted/styled cells, perhaps the problem is related to (also) rendering cells that are neighbors of the relevant range?

Repro in 7.4.5 and in:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d8e6b488ceaff7c88856ebcfcfec14d2d8cd7652
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL threaded

The Version field in this bug report should be modified if this can be reproduced in earlier versions too.
Comment 7 David Lynch 2023-08-25 07:39:04 UTC
This bug is still present in 7.6 and is causing me problems.

Version: 7.6.0.3 (X86_64) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded