Created attachment 172408 [details] Sample File Border formatting in LibreOffice works using a logic that is the opposite to all other office suites. In LO, if the user selects a Border Color, it gets instantly applied before he/she chooses which borders are to be changed. And later, if the user wishes to keep changing border colors using the same color, he/she needs to keep selecting the same color again at each iteration. For clarification, follow the steps: 1) Download the sample file 2) Select the first row in the table 3) Choose a color (f.i. red) using the Border Color button in the Table toolbar 4) Note that all borders in the row will be changed to the selected color 5) Now suppose you want to apply the same border color to the last row; so select the last row and click the "Borders (Shift to Overwrite)" button and select all borders 6) The borders will be painted in black, instead of red 7) Notice that the "Border Colors" button retained the "Red" color, but it did not get applied; so if the user wants to apply red again, he/she needs to select the red color again using the "Border Colors" button The expected behavior would be: 1) Download the sample file 2) Select the first row in the table 3) Choose a color (f.i. red) using the "Border Color" button in the Table toolbar (Nothing changes in the table) 4) To apply the border the user now has to use the "Borders (Shift to Overwrite)" button to choose which borders are to be changed 5) Now suppose you want to apply the same border color to the last row; so select the last row and click the "Borders (Shift to Overwrite)" button and select all borders 6) The borders will be painted in red, using the same color that is already selected in the "Border Colors" button (no need to click this button again, unless the user wants to use a different color) The expected behavior described above is what happens in other office suites (MS Office, Google Docs and OnlyOffice). Hence, for new users coming to LibreOffice, the current steps to format borders will look like a bug. And they also involve additional steps that make the formatting process cumbersome.
confirm in Windows 7 Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ac80ec817eb07c77a51bc0729985a473c734182e CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: CL
no repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ac80ec817eb07c77a51bc0729985a473c734182e CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
Could confirm the buggy behavior. When changing the position of the borders new created borders are always set black. When changing the style or the color you couldn't change this only for a new created border. It will change this property for all borders. The only possibility to get cells with different borders in different colors (and different styles) is to use dialog for Table Properties. Tested with different versions of LO, special with Version: 7.2.0.2 / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded on OpenSuse 15.2 64bit rpm Linux
Can we make this a duplicate of bug 143249 and discuss the envisioned solution and its issues there?
(In reply to Heiko Tietze from comment #4) > Can we make this a duplicate of bug 143249 and discuss the envisioned > solution and its issues there? I don't see much in this bug for changing the buttons in symbol bar. Most of the discussion is about changing the dialog for table properties.
Created attachment 174209 [details] Video showing the bug I took a look at bug 143249 and in my opinion it is not a duplicate of this bug (142541). This bug reports a problem related to how the "Borders" control sends out the command to change the table's border color. For some reason it is not considering the color chosen in "Border Color". I attached a video that shows the problem in more detail. In short, if (i) I select a range of cells, (ii) then select a color in the "Border Color" control and then (iii) I select a border to apply in the "Borders" control, the selected color is not applied. This video was captured using LO 7.2 beta 1. Version: 7.2.0.1 / LibreOffice Community Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded
Okay, got it. The border type overwrites the color. It's a consequence from the fact that color pickers don't show the actual value but keep the last choice. Happens also in Writer for font color where the advantage becomes clear: if we change this you'd have to switch back from black to red after selection. IMHO NAB (admittedly also WF).
Created attachment 174495 [details] Video showing how the same features work in Excel (In reply to Heiko Tietze from comment #7) > IMHO NAB (admittedly also WF). Hi Heiko. I agree that this may be NAB but an enhancement request. However i think WF wouldn't be suitable here. It is hard to explain to new users that if he/she selects a color and then applies a border, the selected color won't be applied. Any new user will see this as a bug. If you test the same behavior in Excel (see attached video) you can select a color and then apply it to as many borders as you want. This is the behavior most users will expect.
We discussed the issue in the design meeting. And it's unclear why it shouldn't be possible to consider what color is set in the color picker. So let's do it. And we have to take into account the other border attributes too.
Dear Rafael Lima, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug is still the same in Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded