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().
Created attachment 185128 [details] Exhibits bug 153388
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?
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).
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.
Created attachment 185160 [details] Exhibits bug more clearly
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.
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
This bug is still present: Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: CL threaded