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)
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.
LibreOffice 4.2.3.2 (Build ID: 7c5c769e412afd32da4d946d2cb0c8b0674e95e0) no changes. Almost all of line style displayed as a single line.
Created attachment 96688 [details] borders_win7 Reproducible with LO 4.3 Windows 7
Bug still reproducible with LO 4.2.4.1 (Calc & Writer) on all platforms.
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)
*** Bug 77052 has been marked as a duplicate of this bug. ***
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)
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
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
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Adding Cc: to Kohei Yoshida
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
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.