Created attachment 97259 [details] ODS spreadsheet with 3 border styles LibreOffice no longer displays the correct border line style in the spreadsheet (although it looks correct in Print Preview) This is a regression in 4.2.1.1 (works correctly in 4.2.0.4) and it's still broken in 4.2.3.3
Reproducible, tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha0+ Build ID: d2555ebb240fea2780f152e5ea39d145aab508fe TinderBox: Win-x86@39, Branch:master, Time: 2014-04-14_07:59:52 Kind regards, Joren
Whats is going on? Now is Libreoffice 4.2.5.1 and bug is still reproducible. Where is stability of LibreOffice?
bibisected: d8a9d450e6e5221de4d4659bac6e315d73388d3b is the first bad commit commit d8a9d450e6e5221de4d4659bac6e315d73388d3b Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun May 11 03:38:01 2014 +0000 source-hash-3034b144d0062e9c4394b901aded43fec117ed11 commit 3034b144d0062e9c4394b901aded43fec117ed11 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Tue Jan 21 12:22:35 2014 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Tue Jan 21 12:25:20 2014 +0100 OfficeBean example does not work on OS X (where officebean.jar is not built) Change-Id: I18c9d0fa0a74cbbdad43bd99d87dc6414a0264d2 :100644 100644 5dd420896fae2b5044048deb9a71598d3d741138 9e1f3c5fa2f448236193288c5944c23614f7384e M ccache.log :100644 100644 7659db9e2154632a45523aeb7532787e77dccb43 bd7bdda54adab50bc28d3004f63989cb1e918cc2 M commitmsg :100644 100644 845a0da3ea8bfc62bcc5e882cca9635f1215b718 0e5478ad12a5a0df40a416f5007568bcced28edc M make.log :040000 040000 d1aeaaac55ba3ddaf838046f99adf343aaeeb0e4 e80ab87c6308a3789ba3b6de928a379175541feb M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d # bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb # bad: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b git bisect bad e1d0365cd2b073a859f59ad0a4584385a66dc611 # bad: [98a55bf95f3ec29298751fd8fba76dd2236dce43] source-hash-58dfc97ca697875c36b7ddf14f5505a93d7b9cf8 git bisect bad 98a55bf95f3ec29298751fd8fba76dd2236dce43 # good: [92ca7e7dd4470107453ce3e99f3675387f91bf24] source-hash-ed5065d8b080bfaf51ea1232cebf3ff72af1e640 git bisect good 92ca7e7dd4470107453ce3e99f3675387f91bf24 # bad: [c3997dfb709772c28f4b90559431662e3a81d651] source-hash-d803483f6a5938b0d0708b8db74b30c511dd8e31 git bisect bad c3997dfb709772c28f4b90559431662e3a81d651 # good: [7faf01595aded0c825d2d9e50c62c688e91c1496] source-hash-78a61583c266a1fd222cd78c912e35e93f7010d3 git bisect good 7faf01595aded0c825d2d9e50c62c688e91c1496 # bad: [6739367b3e6a11533d730114db0f74980bace913] source-hash-1b1031a8f6aa3ed7eeb1516aac6c327b1fddea4b git bisect bad 6739367b3e6a11533d730114db0f74980bace913 # bad: [d8a9d450e6e5221de4d4659bac6e315d73388d3b] source-hash-3034b144d0062e9c4394b901aded43fec117ed11 git bisect bad d8a9d450e6e5221de4d4659bac6e315d73388d3b # first bad commit: [d8a9d450e6e5221de4d4659bac6e315d73388d3b] source-hash-3034b144d0062e9c4394b901aded43fec117ed11
This behaviour changed across the set of commits ec1a3157c1851dcb481f402ec25aa38fa9e7c51c..30f97564f86ff2fff3e682a14191db0d841df0cf 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 commit ae22838d2ff4d388e97c30317a6a9f83e652a06a Author: Kohei Yoshida <kohei.yoshida@collabora.com> Date: Mon Jan 20 11:10:52 2014 -0500 Better on-screen drawing of vertical dashed lines. Change-Id: I53d5f8b0278d1228cd941221a07cd360943c5ce6 commit b3b57c7a3a43a056217c72716d18bdeced029b66 Author: Kohei Yoshida <kohei.yoshida@collabora.com> Date: Mon Jan 20 10:12:53 2014 -0500 Same solid line treatment for vertical lines during on-screen drawing. Change-Id: Idb352dc2afeb2ee7b48620c972c2a186209228ea commit 82599357ae6066b002ca2bd2b7060b26e51ba00f Author: Kohei Yoshida <kohei.yoshida@collabora.com> Date: Mon Jan 20 10:04:26 2014 -0500 Add vertical lines for testing. Change-Id: I93d3613547b74a37cebbb6e791e0d23ea405401b
(Missed quoting the earliest commit in the above range) commit ec1a3157c1851dcb481f402ec25aa38fa9e7c51c Author: Kohei Yoshida <kohei.yoshida@collabora.com> Date: Sat Jan 18 23:02:05 2014 -0500 Better pixelization of dashed lines for screen rendering. Now the dashed lines are evenly placed on screen. For now, horizontal lines only. I'll work on vertical lines later. Change-Id: I474e9c8214e5f079ea2cfca12b35381d8fcf2ae1
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
The issue seems to be pieces similar to this: double nThick = rtl::math::round(rSource.getLeftWidth()); ... if (basegfx::fTools::equalZero(nThick)) { // Dash line segment too small to draw. Substitute it with a solid line. ... from http://opengrok.libreoffice.org/xref/core/drawinglayer/source/processor2d/vclpixelprocessor2d.cxx Since nThick is a very small number like 0.07 (depends on zoom), it will get rounded to zero, and then the line is substituted. Removing the rounding will produce acceptable results in default rendering mode, but the dashed/dotted lines look really bad with OpenGL rendering (probably unrelated, but still not an improvement from users' perspective). That, and some effort should be put into properly understanding the whole code.
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
Yes, this regression still occurs in LO 5.3.6 and 5.4.2 under Windows 7.
This is now partially fixed since branch 6.0. The dotted line type still has some problems in the vertical lines. I no longer use LibreOffice, so if someone has the time it would probably make sense to close this Bug and open a new one with the limitation mentioned before.
Created attachment 146005 [details] ODS compared in LO versions As Pedro noted, there was a change. Screen preview depends on zoom factor. Dashed border looks good now (for zoom >50%). Dotted border doesn't look good for 100% but looks better with 120%.
*** Bug 120868 has been marked as a duplicate of this bug. ***
(In reply to Timur from comment #14) > *** Bug 120868 has been marked as a duplicate of this bug. *** Please see BUG 120408 and attachment. this has worked and displays perfectly in 5.4.7.2 and earlier but not latest versions.
Bug 120408 is fixed now with a very recent commit from Armin (313392119522c21a6ecd14403d6f92c948149df7), let's close this as well as WORKSFORME.
Yes. Thanks Armin and Aron!
Thanks but as i am new to this how can i check this out myself?
(In reply to johnmcfarlane01 from comment #18) > Thanks but as i am new to this how can i check this out myself? You can find daily builds for different platforms on this link: https://dev-builds.libreoffice.org/daily/master/ Since you reported using Windows in your bug report, Win-x86_64@42 should have builds suitable for you, grab the latest one (mind the date of the build, it should be after the commit, which in this case was pushed on the 25th). Thanks for the fix, Armin!
(In reply to Aron Budea from comment #19) > (In reply to johnmcfarlane01 from comment #18) > > Thanks but as i am new to this how can i check this out myself? > > You can find daily builds for different platforms on this link: > https://dev-builds.libreoffice.org/daily/master/ > > Since you reported using Windows in your bug report, Win-x86_64@42 should > have builds suitable for you, grab the latest one (mind the date of the > build, it should be after the commit, which in this case was pushed on the > 25th). > > Thanks for the fix, Armin! Looks much better but still darker and heavier dotted line compared with my typical spreadsheet attachment display in 5.4.7.2. Vertical thick left hand border lines adjacent to hidden columns not displaying either.
One issue per bug. Last issue is something else, maybe Bug 116051.