Download it now!
Bug 76166 - VIEWING: 0.05pt dashed cell borders are always shown solid
Summary: VIEWING: 0.05pt dashed cell borders are always shown solid
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.3.1 rc
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 77052 (view as bug list)
Depends on:
Blocks: Cell-Border
  Show dependency treegraph
 
Reported: 2014-03-14 10:40 UTC by Chris
Modified: 2017-11-09 07:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
screens_borders (106.68 KB, image/png)
2014-03-14 10:40 UTC, Chris
Details
borders_win7 (84.54 KB, image/png)
2014-03-31 22:40 UTC, Chris
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris 2014-03-14 10:40:30 UTC
Created attachment 95794 [details]
screens_borders

Borders line style displayed incorrectly in cells.
Buggy with LO 4.2.1 to 4.2.3.1 (Build ID: 3d4fc3d9dbf8f4c0aeb61498a81f91c5b7922f13)
Linux (Debian)
Comment 1 A (Andy) 2014-03-14 22:43:22 UTC
reproducible with LO 4.2.1.1 (Win 8.1)

Steps Done:
1. Open WRITER
2. Select several cells
3. Go to FORMAT -> CELLS -> tab BORDERS
4. Select the dashed line style and apply it in the left USER-DEFINED section

Result: No dashed line, but a single line is visible.
Comment 2 Chris 2014-03-27 12:37:48 UTC
LibreOffice 4.2.3.2 (Build ID: 7c5c769e412afd32da4d946d2cb0c8b0674e95e0) no changes. Almost all of line style displayed as a single line.
Comment 3 Chris 2014-03-31 22:40:14 UTC
Created attachment 96688 [details]
borders_win7

Reproducible with LO 4.3 Windows 7
Comment 4 Chris 2014-04-17 18:43:50 UTC
Bug still reproducible with LO 4.2.4.1 (Calc & Writer) on all platforms.
Comment 5 Buovjaga 2015-01-16 06:58:50 UTC
Not reproducible for me.

Win 7 64-bit Version: 4.4.0.2
Build ID: a3603970151a6ae2596acd62b70112f4d376b99

and Version: 4.5.0.0.alpha0+
Build ID: b3b4bbaf6cbd2226b659fea7d6ae473ccf84e9dd
TinderBox: Win-x86@39, Branch:master, Time: 2015-01-12_06:13:44

Ubuntu 14.10 64-bit Version: 4.5.0.0.alpha0+
Build ID: 7201fa0dddd7dd0352f69fd2b2b64efcb361ccad
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-01-11_23:28:55

and Version: 4.3.3.2
Build ID: 430m0(Build:2)
Comment 6 Matthew Francis 2015-01-16 07:15:26 UTC
*** Bug 77052 has been marked as a duplicate of this bug. ***
Comment 7 Matthew Francis 2015-01-16 07:21:01 UTC
I see what's going on here.

The issue only applies to 0.05pt lines. Anything thicker than that is shown correctly with dots/dashes provided that the zoom level is high enough. 0.05pt lines, however, are shown solid at any zoom level.


(Adjusted title, and set Component to Spreadsheet - this is Calc specific)
Comment 8 Matthew Francis 2015-01-16 07:33:00 UTC
Looks like a regression. Bibisect results from 43all:

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4
git bisect start 'latest' 'last42onmaster'
# bad: [4fcd68ce4979f85fda4568f4b419a4b41d07345f] source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e
git bisect bad 4fcd68ce4979f85fda4568f4b419a4b41d07345f
# bad: [0d4c20a601a3cfff27d6685d0e81463086bd9d74] source-hash-f1b1e73227471192682d303a58618ca8bd65a74d
git bisect bad 0d4c20a601a3cfff27d6685d0e81463086bd9d74
# skip: [18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf] source-hash-fe506f34f2dccb6562935fe4dfbc1fe6d609dec8
git bisect skip 18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf
# skip: [18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf] source-hash-fe506f34f2dccb6562935fe4dfbc1fe6d609dec8
git bisect skip 18ee045c7e35e5ae98cffaafd56fb6fb37d7afcf
# good: [9fe7b44f1975d64e3009c31341187c53c8e3a2b8] source-hash-7f5494f3c4bf14209a119c6b21c02e10075503ae
git bisect good 9fe7b44f1975d64e3009c31341187c53c8e3a2b8
# good: [f1e56b0f09e0a75b8970a8b9892298f0ca210200] source-hash-eeeefd6fd87b3cff18ba9078869bdfcd0e351d6f
git bisect good f1e56b0f09e0a75b8970a8b9892298f0ca210200
# bad: [d8a9d450e6e5221de4d4659bac6e315d73388d3b] source-hash-3034b144d0062e9c4394b901aded43fec117ed11
git bisect bad d8a9d450e6e5221de4d4659bac6e315d73388d3b
# skip: [bde12e7d6eef3d657ebdf62cb5442490fb90d899] source-hash-03725013b64e74473e1a9e925b24927e7e61d412
git bisect skip bde12e7d6eef3d657ebdf62cb5442490fb90d899
# good: [92ca7e7dd4470107453ce3e99f3675387f91bf24] source-hash-ed5065d8b080bfaf51ea1232cebf3ff72af1e640
git bisect good 92ca7e7dd4470107453ce3e99f3675387f91bf24
# skip: [67ae616bc846d2a4e05661a5980287cb38b8a455] source-hash-6069b5162281ccc88eb242991a115197d0893fb4
git bisect skip 67ae616bc846d2a4e05661a5980287cb38b8a455
# skip: [7faf01595aded0c825d2d9e50c62c688e91c1496] source-hash-78a61583c266a1fd222cd78c912e35e93f7010d3
git bisect skip 7faf01595aded0c825d2d9e50c62c688e91c1496
# only skipped commits left to test
# possible first bad commit: [d8a9d450e6e5221de4d4659bac6e315d73388d3b] source-hash-3034b144d0062e9c4394b901aded43fec117ed11
# possible first bad commit: [7faf01595aded0c825d2d9e50c62c688e91c1496] source-hash-78a61583c266a1fd222cd78c912e35e93f7010d3
# possible first bad commit: [67ae616bc846d2a4e05661a5980287cb38b8a455] source-hash-6069b5162281ccc88eb242991a115197d0893fb4
# possible first bad commit: [bde12e7d6eef3d657ebdf62cb5442490fb90d899] source-hash-03725013b64e74473e1a9e925b24927e7e61d412
Comment 9 Matthew Francis 2015-01-16 10:32:05 UTC
There are lots of commits in the bibisect range relating to border rendering, but the most directly responsible are the three below.

Reasonably enough these have to do with preventing borders become invisible at different zoom settings, so the code is essentially working as currently designed, but given that it is already possible to set the line thickness so that the border is 1px and dashed (correctly), perhaps it is still reasonable to retain the dashing even when the line width is overridden to ensure visibility?


commit 01104522ef890bb535994311e627ba1bbfff023c
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Mon Jan 20 12:03:39 2014 -0500

    Ensure that the pixel line is at least 1 pixel wide.
    
    Without this, some dashed lines may not get drawn at all at some zoom levels.
    
    Change-Id: I273c1548325d14f56618df8ca4166aac58a3ff3f

commit 41bee5b83102760a6da7eaca3b770e4c4e310d4d
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Mon Jan 20 11:48:36 2014 -0500

    Do the same when the pixel thickness is zero.
    
    Change-Id: Icfbb295abb19cf58477f4f14f4a7294a540151c2

commit 30f97564f86ff2fff3e682a14191db0d841df0cf
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Mon Jan 20 11:41:41 2014 -0500

    Substitute dashed line with a solid line at lower zoom levels.
    
    Change-Id: I0437409b6a5d6163fadf777df5c028950727e786
Comment 10 Robinson Tryon (qubit) 2015-12-13 11:09:35 UTC Comment hidden (obsolete)
Comment 11 Xisco Faulí 2016-10-03 09:24:09 UTC
Adding Cc: to Kohei Yoshida
Comment 12 QA Administrators 2017-10-23 14:05:02 UTC Comment hidden (obsolete)
Comment 13 Kevin Suo 2017-11-09 07:24:58 UTC
I do not reproduce this in version 5.3.7.2, Fedora 26 amd64. Please re-test, and set to RESOLVED WORKSFORME if the bug is gone.
Comment 14 Xisco Faulí 2017-11-09 07:44:28 UTC
Yep, Using a dashed border with a width of 0.05pt or less the border is displayed correctly in

Version: 6.0.0.0.alpha1+
Build ID: 5e0022c90c4125a1590b3688dfec73c271b7aedd
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: th-TH (ca_ES.UTF-8); Calc: group

Probably fixed by recent Armin's work on borders.