Bug 142541 - Border formatting in Impress and Writer Tables does not consider the selected Border Color
Summary: Border formatting in Impress and Writer Tables does not consider the selected...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.1.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Borders
  Show dependency treegraph
 
Reported: 2021-05-28 13:31 UTC by Rafael Lima
Modified: 2021-08-30 07:57 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample File (14.17 KB, application/vnd.oasis.opendocument.presentation)
2021-05-28 13:31 UTC, Rafael Lima
Details
Video showing the bug (914.89 KB, video/x-matroska)
2021-08-11 12:05 UTC, Rafael Lima
Details
Video showing how the same features work in Excel (2.80 MB, video/mp4)
2021-08-23 14:43 UTC, Rafael Lima
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Lima 2021-05-28 13:31:04 UTC
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.
Comment 1 Oksana Ivanova 2021-07-31 19:47:12 UTC
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
Comment 2 Diana 2021-08-02 15:04:07 UTC
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
Comment 3 Robert Großkopf 2021-08-03 10:44:47 UTC
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
Comment 4 Heiko Tietze 2021-08-11 10:05:29 UTC
Can we make this a duplicate of bug 143249 and discuss the envisioned solution and its issues there?
Comment 5 Robert Großkopf 2021-08-11 10:24:56 UTC
(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.
Comment 6 Rafael Lima 2021-08-11 12:05:42 UTC
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
Comment 7 Heiko Tietze 2021-08-23 13:56:33 UTC
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).
Comment 8 Rafael Lima 2021-08-23 14:43:41 UTC
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.
Comment 9 Heiko Tietze 2021-08-30 07:57:05 UTC
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.