Steps how to reproduce with server installation of "Version 4.1.0.0.alpha0+ (Build ID: 576da8db5577f84d9c7e0e40ef3e166a7938c98) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-02-11_23:54:45" ENGLISH UI / German Locale on German WIN7 Home Premium (64bit) with own separate User Profile: 1. Open Attachment 67259 [details] for Bug 46393 2. Toggle "Grid lines off" in Formatting Toolbar 3. Normal View - Zoom 100% Expected: Range M13:N14 ("44") shown with borders Actual: No borders Same in Page break view and with "66" With zoom 150% bad effect disappears I can't see influence of hardware acceleration or anti aliasing. Was ok with 3.6.5, so regression.
I cannot confirm this. Version 4.1.0.0.alpha0+ (Build ID: 871712ad62bb01359c29713a148a5673e26df1a) Bodhi Linux +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If it exists must be Windows issue, I'll ping someone to test on Windows
(In reply to comment #1) Yes, that problem might be to very particular circumstances. 64 bit AMD Phenom II X4 955 Processor 3.2 GHz, 4GB RAM, Graphic Card: NVIDIA GeForce GT 430, Monitor HANNS-G HL225DBB 1920 x 1080 For me already a problem with * parallel Dev. Installation of "LODev 4.0.1.0+ - English UI / German Locale [Build ID: 9b70bf62e6b5319e282cd3533c90216aabccfe5)]" {tinderbox: @6, pull time 2013-02-03 09:04:55} on German WIN7 Home Premium (64bit) with newly created user profile ….\LODev\401\ * with Server Installation of "LibO 4.0.0.3 rc - GERMAN UI / German Locale [Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)]" {tinderbox: @6, pull time 2013-01-31 11:30(?)} on German WIN7 Home Premium (64bit) with separate new User Profile * server installation of "LOdev 4.0.0.0.beta2+ - ENGLISH UI / German Locale [Build ID: 6738ae52bd075dc6478dedfeddc60d1c25cffcb)]" {tinderbox: Win-x86@6, pull time 2013-01-04 23:41:48} on German WIN7 Home Premium (64bit) with own separate User Profile ** Result with this Version: borders reappear with Menu Tools -> Options -> LibO -> View -> Scale 80%', same with pull time 2013-01-04 23:41:48 above Was Still ok with * Server-installation of Master " 3.7.0.0.alpha0+ – ENGLISH UI [Build ID: f2e622]" {tinderbox: Win-x86@16, pull time 2012-10-06 09:31:39} on German WIN7 Home Premium (64bit) UserInstallation=$SYSUSERCONFIG/LOdev/3 With 4.0.0.3 tested: with app. Zoom 115% horizontal boders become visible, with 117% vertical ones @Vitiriol: can check this one?
Created attachment 74773 [details] Borders issue
(In reply to comment #2) > @Vitiriol: > can check this one? I can confirm with zoom between 110% and 140% on my system. Attached screenshot.
I have confirmed this as well using Windows 8 64-bit and 4.1.0.0.alpha0+.
Increasing priority to High as it's a recent regression, hopefully the issue can be tracked down
I will try to have a look at this ( although I have no clue how successful I might me ) - at least I will try and push back the bug to the list if I don't get anywhere
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=46d122d4cc405c4070eb4945abd20cdf3a5fac33 Revert "Always disable anti-aliasing for drawing cell borders." fdo#60805 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aab7a316dc127f71e530552cebfb34d5b8f5fa19 Revert "Revert "Always disable anti-aliasing for drawing cell borders." fdo#60805" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So, reverting that commit will not fix this fundamental issue, I'm afraid. With deep regrets, I had to revert the above revert. The problem is deeply rooted to the new drawing layer especially wrt the handling of anti-aliasing options. Reverting it may "fix" the problem for this particular use case, but it will re-surface when the anti-aliasing option is turned off in the Options dialog. The right fix would involve 1) modify the drawing layer code to allow caller to enable disable anti-aliasing on the spot, without making that a global configuration option (which inspired my earlier change), and 2) modify the down-resolution of borders without making them disappear. I'm starting to think that maybe we shouldn't use the shared drawing layer code to draw cell borders. So many problems with so little control...
(In reply to comment #10) > So, reverting that commit will not fix this fundamental issue, I'm afraid. > With deep regrets, I had to revert the above revert. > I don't believe restoring hack to turn off antialiasing for border drawing is any better of a solution, can only judge from my own system where the opposite seems to be better e.g. always turning it on. But... whatever, returning this to the list
(In reply to comment #11) > (In reply to comment #10) > > So, reverting that commit will not fix this fundamental issue, I'm afraid. > > With deep regrets, I had to revert the above revert. > > > > I don't believe restoring hack to turn off antialiasing for border drawing > is any better of a solution, can only judge from my own system where the > opposite seems to be better e.g. always turning it on. But... whatever, > returning this to the list just to make it clear, the orig patch that I reverted ( that causes this bug ) was committed to solve some problem with 'thicker' than expected borders, I can't tell whether this patch still fixes this ( I suspect not ) but I have no details or document to check against as there is no bug number associated with that patch. However I don't see ( and haven't seen ) any such issue in the test document or other's I have looked at ( that's not to say it doesn't happen, just I can't tell any more than what I have experienced ) I have a feeling though that perhaps these border issues might have been improved/fixed by various fixes from mstahl regarding hairline border detection and clipping. The test document contains a pretty nice set of cells with various border styles and border line widths, in every instance with the patch mentioned above 'reverted' the display seems to be much much better. In fact in addition to the dissapearing border lines I also see lots of nasty artefacts in the border display [1] ( even at 100% zoom ) and additionally border width differences that don't seem to show up [2]( e.g. much thicker lines appearing the same as thinner ones ) [3] double line border appearing to be filled in [1] look at the jagged border intersection with cells marked 62,63 [2] look at cells marked 53,54 the line width of 54 is twice that of 53 but it looks the same [3] the funny thick borders on parts of the cells marked with 74,75 ( see bottom of the screen shot ) Regardless of what the 'proper' solution might be ( and yes probably some deep analysis by some drawninglayer enabled person needed to fix that ) I don't think hard coding the antialiasing to off when drawing calc cell borders which seems to clearly make things worse is the correct solution. at the very least imho that patch *should* be reverted at least to give users some flexibility. I think at least this bug is serious enough that it be on the 4.0 MAB
Then, you and Michael Stahl decide the fate of this. You don't need to get my approval.
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b3f3ce53a26ba52d27784a2f9adbffcbd6169f3 Revert "Always disable anti-aliasing for drawing cell borders." fdo#60805 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=415b47827fae8ad0c2a747ca9b062170f00f1e7c&h=libreoffice-4-2 Revert "Always disable anti-aliasing for drawing cell borders." fdo#60805 It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
My fix for Bug 73487 should address this problem too. It's in 4.2.1.
Oh, and please don't reopen this bug anymore. For any new border line issues, file a new one.
and only of course if you can verify issues on 4.2.1 or later - do not file new bugs that you see on 4.1 unless you can confirm they are on 4.2 as Kohei has just said major work was done in 4.2. Thanks!