In Calc, borders for merged cells are partially shown. Steps: 1. Apply 0.75pt borders to range C4:J27. 2. Merge cells C8:C13, and E8:J18. 3. Scroll up and down. Result: A portion of the merged cell borders are not showing. Version: 6.0.0 alpha 1 on master updated today. Both in Ubuntu 17.10 and Fedora 26 x64.
I confirm with Version: 6.0.0.0.alpha1+ Build ID: 474f0ec77f0458c9403a2e8d7452fa1885bd8a60 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group Ok with Version: 5.4.4.0.0+ Build ID: 1649d5dfaca6fb29e75bd18e3e0d4f985a9eebeb CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
This is a regression, I am doing the bibisecting.
9b43cc899c0a78e7ad7bbf554c0881ea00241a69 is the first bad commit commit 9b43cc899c0a78e7ad7bbf554c0881ea00241a69 Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Sat Sep 16 07:14:13 2017 +0200 2017-09-16: source-hash-f9cbf67fb2cf817b6d201604eb7d4bf6182a1392 :100644 100644 89bfae300258fbfdd5413edd9066b7326db2cda7 d2ef86a3f25e22b86c75c822246a9afbf74eb967 M build-info.txt :040000 040000 f6f679ab22a9250095363a1bde4f3ddd0664efce 9f3b12da020df81db8264d8bee2aa8f015fc7f32 M opt $ git bisect log # bad: [3da73c8df3d4eb38caa5393488ac06e92ba20596] 2017-11-10: source-hash-eaa9cf6a3069fba3d82c046f0041bfb537d9e648 # good: [e842536767587089b384a83cd1cfb053888db0b9] 2017-05-19: source-hash-b5d72331053ce19942463ac6e688eac74e01e649 git bisect start 'master' 'oldest' # good: [1755ff4a846002367e16b78ba212affdab7df1e2] 2017-08-14: source-hash-1845eec0198200bbdac636057d9e3f62e326e3ac git bisect good 1755ff4a846002367e16b78ba212affdab7df1e2 # bad: [fdb4bb657dd59069cdd1d68b63faf3c04b3c794e] 2017-09-27: source-hash-892c719fffa06de4c7aeab497326cad7bae9e5c6 git bisect bad fdb4bb657dd59069cdd1d68b63faf3c04b3c794e # good: [df6c1f492a4a6df2274a7a44fabfd607ad41ab86] 2017-09-05: source-hash-fc61be93c60967bf1d6bcffcada8189016d4530e git bisect good df6c1f492a4a6df2274a7a44fabfd607ad41ab86 # bad: [9b43cc899c0a78e7ad7bbf554c0881ea00241a69] 2017-09-16: source-hash-f9cbf67fb2cf817b6d201604eb7d4bf6182a1392 git bisect bad 9b43cc899c0a78e7ad7bbf554c0881ea00241a69 # good: [68e7ebb36920eda5204e787e9e80bdfbc83ecaf1] 2017-09-10: source-hash-fdc85f759c4ef69f4ccdb7f160ad4bce7e61b231 git bisect good 68e7ebb36920eda5204e787e9e80bdfbc83ecaf1 # good: [a3422c5a9182617fbefe9d6515022cea0a0b424e] 2017-09-13: source-hash-33ead25229d308f98fa171412f2937ca0ba976e9 git bisect good a3422c5a9182617fbefe9d6515022cea0a0b424e # good: [fe91723c236f7a2af3b519d318baa1f5a8f39ee0] 2017-09-15: source-hash-031217619cf98fa527ba383938ac49f600d5c5d2 git bisect good fe91723c236f7a2af3b519d318baa1f5a8f39ee0 # first bad commit: [9b43cc899c0a78e7ad7bbf554c0881ea00241a69] 2017-09-16: source-hash-f9cbf67fb2cf817b6d201604eb7d4bf6182a1392
Created attachment 137698 [details] sample
Regression introduced by: author Armin Le Grand <Armin.Le.Grand@cib.de> 2017-08-30 18:40:32 (GMT) committer Armin Le Grand <Armin.Le.Grand@cib.de> 2017-09-15 10:58:03 (GMT) commit a9c59cbfb9e16469b389db0b4d6befe196d0e2a0 (patch) tree a031682ae21ec46bb9c6e1e30b0110213e8e3dac parent fe14ddf25003c0f79f9f8a249bc22d45f57a0068 (diff) borderline: Preparing further to use CellCoordinateSystem Multiple cleanups, made svx::frame::Style a std::shared_ptr class, preparing basing all border stuff on transformations, so it will need a CellCoordinateSystem. Added stuff to get this Coordinate System from the svx::frame::Cell using the Frame and knowledge about ownerships Bisected with: bibisect-linux64-6.0 Adding Cc: to Armin Le Grand
Took a look, which 'portion of the cell borders' is not shown? This is not precise enough to get a clear picture what might be wrong, please give more information. (PS: CTRL+SHIFT+R is repaint in calc, there might still be calc-specific scroll/repaint issues)
Created attachment 138064 [details] screenshot In the screenshot, the left-bottom part of the borders for merged cells are missing.
Created attachment 138404 [details] merged-cell-border.ods The new test document with corner cases
Created attachment 138405 [details] merged-cell-border.pdf The worse thing is that, the borders are broken also in exported pdf pages. And, if the first column contains merged cell and the merge continues to next page, the borders are not rendered correctly (falls to the bottom of the page)
Created attachment 138406 [details] merged-cell-border-good.pdf (in libreoffice5.4) This is the expected result.
So there is too much shown, not something missing? Plus some borders being too wide (2px as it looks?). Assuming comment 10 shows the correct, comment 9 shows the wrong (and current?) result. This was not completely clear, esp. as orig description states 'A portion of the merged cell borders are not showing'. Please correct when I'm wrong, just want to be 100% sure what the error is here.
(In reply to Armin Le Grand (CIB) from comment #11) So there may be two different issues here. Let's focus on the issue as described in the original report here. Steps: 1. Apply borders to range C4:J27. 2. Merge cells C8:C13, and E8:J18. 3. Scroll up and down. Result: A portion of the merged cell borders are not showing. Expected: All borders shown.
Created attachment 138855 [details] screenshot Still reproducible in: Version: 6.1.0.0.alpha0+ Build ID: 6a29d733651eb307ee8a6c3cf1bc64579070e53a CPU threads: 4; OS: Linux 4.14; UI render: default; VCL: gtk3; Locale: zh-CN (zh_CN.UTF-8); Calc: group threaded Fedora 27.
Compared with local installed Version: 5.1.5.2 (x64), indeed there all merged cell borders get shown always, so there seems to be a regression. The example is too huge for debugging, I will try to create a minimal example. BTW, the definitions are correct, it is only a repaint error (as CTRL+SHIFT+R shows). Print, PDFexport seem to merge cell borders 'over' page boundaries, need to check that, too. Thus, trying to find a minimal example...
Could reproduce with much smaller cells. Problem seems to have to do with scrolling in merged cells when top-left is not visible in that in-between state. Then merged cells seem not to handle their merged borders correctly - they assume that it's handled from the start cells (leftmost, topmost). If that one is not shown in that in-between state, there may be a problem.
*** Bug 115091 has been marked as a duplicate of this bug. ***
*** Bug 115240 has been marked as a duplicate of this bug. ***
Fixed in Version: 6.1.0.0.alpha0+ Build ID: 75802ae40ae67737ae9e4f1a38434e0587affff6 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Armin, could you please close this as RESOLVED FIXED ?
*** Bug 114402 has been marked as a duplicate of this bug. ***
Fixed with changes for tdf#114934, see there