Created attachment 193705 [details] Video showing the problem Suppose you have vertically merged cells and you add borders to them. If you have multiple such merged cells stacked vertically and start scrolling your document, you'll notice that the top border is not painted when the merged cell is only partially visible. To better understand the bug, see attached video. System info Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 4:24.2.2~rc2-0ubuntu0.23.10.1~lo1 Calc: threaded
Created attachment 193706 [details] Sample ODS file Steps to reproduce: 1) Open the attached "Sample ODS file" 2) Zoom in so that not all merged cells are visible 3) Start scrolling down 4) Notice that when a merged cell is not fully visible, it's top border will not be painted
Although I don't repro this on Windows with a recent 24.8 alpha (or, alternatively, I am not understanding the STR), there is a similar issue in tdf#160654 (scrolling horizontally instead of vertically), which I can repro on Windows.
Created attachment 194164 [details] Sample PNG File Attached is a graphic of the repeated merging of 3-columns x 10-rows. Three borders are missing at the bottom of the screen. Not Reproduced with Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 4; OS: Windows 10.0 Build 10240; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Reproducible with Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Windows 10.0 Build 10240; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded
Based on Comment #3 I am setting this to NEW. Seems like a regression to me.
It is no longer reproduced in versions with a date of 24.05.20. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: e3bd3c7e3178dc091fd002628f052666b4db3be6 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 10240); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
(In reply to nobu from comment #5) > It is no longer reproduced in versions with a date of 24.05.20. Indeed, in a recent build this issue no longer exists. Closing as WFM.
This may not be relevant if you don't intend to fix the current version, but it will be reproduced in version 24.2.3.2. I don't know what will happen in this case, but the current version will continue to be flawed. I'll say it again. Reproducible with Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 4; OS: Windows 10.0 Build 10240; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded (by TexTra)
Loks like a duplicate of bug 159846, and it will also be fixed in 24.2.4. *** This bug has been marked as a duplicate of bug 159846 ***