Created attachment 76934 [details] demo When I select multiple cells and format above to be different color border, borders in between that I did not touch change to no border color. Don't you think it would be better to left alone the cells that were not touched? It is really annoying. I don't know if this is a bug, maybe someone thought this is a future, but I don't like it.
Created attachment 76935 [details] file in demo
Can you please write out very explicit steps to reproduce? I kind of see the issue with your test case but it'll be helpful if you can write out step by step what to do, be as "simple" as you possible can in a format like: 1. Do this 2. Set border 3. Do something else 4. blah This will help tremendously so we can track down the issue. Marking as NEEDINFO, once you provide steps, please set to UNCONFIRMED and we will take a look.
1. open calc 2. select cels with mouse 3. pres Ctrl + 1 4. set width 5. select outer and all inner lines 6. ok 7. select some random cell 8. select a line with mouse within previous selected cells in step 2 9. pressed ctrl down and hold it 10. select second line with a mouse within previous selected cells in step 2 11. release ctrl 12. pres Ctrl + 1 13. select some color 14. set width 15. select upper line in "user-defined" 16. ok vertical lines between cells selected in step 7 and 9 are now with no border. Border that was set in step 4 please see the demo attached
Created attachment 77020 [details] demo
The behaviour that I understand is : - there is a difference between the (unique) active cell (the one with large black border, reported in the heading) and the one or more cells selected (the ones with light blue background) - a format command applies to the selected cell(s) if any, and defaulted to the active cell if there are no selected cells - no ambiguity when the format is the settings of a background, - a precise behaviour is needed when the format is the setting of borders, in order to distinguish between inner and outer borders of the selected cells. And in fact the results appears a little bit fancyful. Just one exemple below. - on a new Calc sheet, click on B3, ctrl-click on C2, C3 and D3, no matter the order, resulting in 4 selected cells (B3, C2, C3, D3) - format > cell > border, select the 2 external horizontals, OK - then click on B6, ctrl-click on C5, C6 and D6, no matter the order, resulting in 4 selected cells (B6, C5, C6, D6) - format > cell > border, select the 2 external verticals, OK - compare the two resuls. Can't we say that the horizontal outline is understandable, while the vertical one is not (in particular, for C6) ? The issue would be : please write down current implemented rules ; if it is impracticable, please imagine, write in docs and implement a rule understandable and useful for users.
Created attachment 87511 [details] 1 beginning - some cells
Created attachment 87512 [details] 2 select cells to get formatted
Created attachment 87513 [details] 3 format ONLY the upper side of the cells - everything else leave untouched
Created attachment 87514 [details] 4 result - cells are ALSO formatted in the middle of previously selected cells - FAIL
Please see the pictures appended (names with explanation) 1 beginning - some cells.png 2 select cells to get formatted.png 3 format ONLY the upper side of the cells - everything else leave untouched.png 4 result - cells are ALSO formatted in the middle of previously selected cells - FAIL.png
Thanks for your scenario. Here is my analysis. Unlike EXCEL, LibO seems to manage 2 conditions for a line to be drawn between 2 cells : being set on behalf of the left/top cell or being set on behalf of the right/bottom cell (the line is a superposition of one line "belonging" to one cell and another line "belonging" to the adjacent cell). I can see that the right/bottom cell prevails in cas of discordant color settings, and that the larger line prevails in cas of discordant width settings (I suppose that this is an evidence of the cells order of processing : line by line beginning with the topmost line, and within a line cell by cell beginning with the leftmost cell). The usage of the left drawing in the dialog box Format > Cell > Border is blank to erase a line, grey to leave it unchanged and lined to set a line with the shown color/width. This drawing is pre-filled as follows : - when the selected area is a rectangle, it is initialised with the current state of borders (white if none, grey if mixed and black/solid if set with a unique width), - when the selected area is not a rectangle, it appears to be always left to blank (LibO doesn't try to pre-fill it). Unfortunatly, that means "erasing the border belonging to the cells". So in your exemple : - your selected area is not one rectangle (but two ...), so your format command results in erasing all line "belonging" to the selected cells except the topmost, not left unchanged (i.e., blank in the left drawing instead of greyed) - the "outer" lines of your two rectangles remain visible on behalf of the adjacent (not selected) cell, - the topmost lines of your two rectangles are set to red, due to the processing order of cells (should you have choosen a color for the bottom line, I guess that it would not have appeared). My analysis seems to also explain the inconsistency between horizontal lines ans vertical lines, in the case I show in comment 5. I think that a deep reflexion should be conducted on this way of processing borders, to confirm (or not) the interest of this great difference with EXCEL (much simpler to understand : the "last" setting of a line prevails over all previous ones, for the unique line between two adjacent cells ; which allows Excel to always pre-fill the left drawing in the dialog box).
I would also like to note that sometimes when opening the property "Format cells", borders are already selected. I have to deselect them, and than select only the one I would like to format. But then the deselected lines gets unformatted, once pres OK on that window. Please see the (lines in 'format cells' property are selected when open that property) demo attached. and the demo (deselected before create new border) is shows me deselected cells and then select the one I want to edit. Hope this helps you
Created attachment 87550 [details] deselected before create new border
Created attachment 87551 [details] lines in 'format cells' property are selected when open that property
Thanks for your new contribution In the 87550 attachment, in the left drawing in dialog box you didn't "deselect" the borders, you "unformatted" them (you didn't greyed the lines, you blanked them). Both 87550 and 87551 confirms my analysis. I now understand that the two-contributor-scheme for borders properties (by the two adjacent cells) is imposed by the notion of cell template, and that it would be definitively impossible to go back to the EXCEL 97 scheme. However, we can't continue with a rule derived from the order of computation, we clearly need a rule that explain statically which attributes win : - the larger wins against the thicker, - the plain line againts the dashed, the dashed against the dotted, - the lighter colored line against the darker... What a mess! What if the border was effectively cut in two parallel adjacent lines, each governed by the adjacent cell border property ? This would take all into account (cell styles, dashed lines, etc). I keep on thinking at the issue...
Confirmed using Version: 4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a Ubuntu 13.10 - Set as New and changed to All plateform - Sophie
** 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 on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
It works fine in Version: 5.0.1.2 on Linux.
FIXED is reserved for when we know what commit fixed the issue. Changing status.