Often when I open existing document and try to delete borders from cell, I found that I can not. Border my be deleted only from cell, where were created. It my be big problem for beginners, and experienced users it slows down. Please, add ability to delete border of cell from adjacent cell.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
remains in LibO 3.5.0 beta 1 in Writer and in Calc
Can you provide a test document with instructions on how to reproduce? Not quite following the issue. Thanks!
Created attachment 63282 [details] example of cell borders problem
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
reopening because it is RFE
I can confirm this, not sure how we would solve it and how often this happens. Took me a few times to realize what you had done with the borders. Enhancement request, low priority. If someone has a suggestion on how to actually implement an enhancement, feel free to suggest
Okay I got it. If a right border is added from B9 you expect to delete it from C9, because it is also its left border. IMHO importance is high...
(In reply to comment #10) > I can confirm this, not sure how we would solve it Hello! I found out what cause this problem (and some more), and what is the solution. Right now, you can set 2 border lines between adjacent cells, because every cell has its 4 own borders. These 2 border lines are placed on the same spot, on each other, so you cannot tell if that line is A2's bottom border or A3's top border or both. And if you set 2 border lines between adjacent cells, and one of them is thicker, then the thinner will not displayed, because these lines are placed on each other. And if you set a red and a black line, and these lines has the same width, you cannot really tell which one will displayed. You can found some different bugreports that caused by the wrong implementation to handle cell borders. These bugs can be solved by another implementation: adjacent cells' border should be a common attribution. If you set B2's bottom border, then it means you also set B3's top border. So insted of 4 own border lines, there is 4 common border lines. (Except for example A1, because it has 2 own and 2 common border lines.) That is how Excel works, and how Calc should works. For more info and pictures, see my bugreport: Bug 67501 - CONFIGURATION: Wrong implementation to handle cell borders. I think this is a high priority bug.
Hm - I'm still not seeing this as a high priority bug. The product works as it was designed to work - you can argue that it can work better (and I'm convinced it can) but that makes it an enhancement. Even if it was a bug, according to the flowchart that many of us use it's a minor bug (perhaps minor - highest, as it can affect a lot of people) but none the less, not critical IMHO - there is a workaround that's relatively straight forward (you just have to check borders for multiple cells, yes a pain in the butt at times) but really - a straight forward workaround that makes it so the "bug" or enhancement doesn't prevent high quality work compared to bugs such as crashes of the product, memory leaks, or bugs that prevent high quality work (with no feasible workaround) are more important. But I'm not the only one who has a say here ;) Other QA members are already cc'ed on the bug so if one of them feels different - they can do as they see fit :) Best, Joel
Bug 67501 should be a replicate / duplicate to this bug.
*** Bug 67501 has been marked as a duplicate of this bug. ***
(In reply to comment #13) You are right. This is not a bug, because the product works as it was designed to work. But the problem is, the product was incorrectly designed. An avarage user expecting if he/she set a bottom border, he/she also set a top border too, because there is only one border between neighbouring cells. The same with left and right borders. This is how Microsoft's Excel, Google Docs, Gnumeric, Calligra Suite (KOffice), Kingsoft Office and so on, and so on works. It affects a lot of people, and the workaround is waste of time, and time is money. This is the reason I think, it is a high priority task to redesigne border handling. It is not so difficult, still makes Calc a lot better, and prevents false bugreports. And do not forget interoperability.
I do agree this would be a valuable enhancement. It does make sense and feels more "natural". But I don't see why we have to place this bug on the MAB (most annoying _bugs_). I'm convinced that enhancement requests does _not_ belong on a MAB. I read all use cases, and I do agree this is in some cases quite annoying, and this enhancement request is great to have in LibreOffice... but it is still not a bug. The way we have to destinguish between enhancement requests like 'how it would reflect on the users' and 'how many users would benefit from it' is to change the priority of it. Therefore I'm going to mark this as ENHANCEMENT HIGHEST and remove it from the MAB. Thanks for your understanding Kind regards, Joren
(In reply to comment #17) Thank you. That is what I wanted. Where can I find this Enhancement highest list? I found something, but I think that is something else. (Vote for Enhancement @ wiki.documentfoundation.org)
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
I have submitted a preliminary patch at https://gerrit.libreoffice.org/#/c/19715/
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e512174f2116d86682037459fd5ab5164e9f510 tdf#34449 : ability of deleting borders of a cell from adjacent cell It will be available in 5.2.0. 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.
@Dennis: Could you please also add a feature description to https://wiki.documentfoundation.org/ReleaseNotes/5.2#Calc best with a screenshot of the dialog pointing out the new checkbox? Thanks.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=da150e5e30cd1c56e5dc6de7201af58bf98b291a fix build, don't pass int as sal_uInt16, tdf#34449 follow-up It will be available in 5.2.0. 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.
(In reply to Eike Rathke from comment #22) > @Dennis: > Could you please also add a feature description to > https://wiki.documentfoundation.org/ReleaseNotes/5.2#Calc best with a > screenshot of the dialog pointing out the new checkbox? > Thanks. Done. Marking this as resolved-fixed. Thanks, Dennis
Notes for unit test writers: Nothing to revert here, you would be testing a new option.