Bug 126678

Description:
This bug came to my attention using a version of LibreOffice 5.1. Since it is an old version, I tried it out with 

Version: 6.1.6.3
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: de-DE (de_DE.UTF-8); Calc: group threaded

and with the latest development version on my computer which is

Version: 6.4.0.0.alpha0+
Build-ID: 9ee5ad5a0b84bfa652da34694ba4f75668f06087
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-07-30_13:21:44
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded

I would not be surprised if this bug is in all previous versions of LibreOffice too.

I have a spreadsheet in LO Calc, the interesting part of which looks like this:

The relevant part of the LO Calc spreadsheet pasted into this LO Writer document (see attached LO Writer document with screenshots)

The properties typeface, boldness, color, slant and background have been assigned to the whole rows by marking them by a click on the row number in LO Calc and then assigning the properties: e.g. the whole line 7 has got a yellow background. All this was done in LO Calc, the results were copied via clipboard to the attached file
.
Then I use Daten>Sortieren and sort the spreadsheet by column B. Because the second column was numbered downward and it is an even number of rows, every row changes its place:

Picture: The relevant part of the LO Calc spreadsheet after sorting.

By the way: After selecting Daten>Sortieren, estimated 5 seconds pass until I can select the sort criterium to be by column B. I think this delay should be sped up!

Despite the fact that the whole spreadsheet was selected for sorting, only the first columns with entries were sorted, as can be seen by the highlight formerly belonging to row 7 which has now moved up, but only for the maximum used column extent (Column D in the example).

I consider this to be an error, since the selection was on everything, not just the used part of the lines. The same bug also happens, if whole rows lines are selected.

This spreadsheet was meant to be used for a similar one to collect data by pushing the old entries in a row to the right if a new measurement is done. Of course, more than one line was meant to be highlighted by a background color. Sorting the table will be a part of the use of it, but if that overthrows the colors and other character properties, that is not as it was expected.
When I add new entries to the existing lines to the right, I expect them to inherit all character formatting properties (e.g. size, font, color, slant, underline and background color) from the respective line. But that’s not what happens: I enter some new text to the empty fields 


Conclusion: The inheritance of color, background, slant and other properties is messed up after sorting a LibreOffice spreadsheet. It looks like the properties are only properly assigned to the cells after the sorting procedure up to the rightmost used column of the spreadsheet.

If the spreadsheet has a maximum size known ahead, this gives a hint how to circumvent the problem in many use cases: Just put an entry to a cell to the utmost right lower corner of the maximum size the spreadsheet will ever grow to. Then there can't be columns to the right of the spreadsheet. - But this circumvention is not a real remedy, it is a bug and it should be corrected:
During sorting, all character display properties (e.g. font, slant, boldness, size, color, background, underlining and possibly all others which may be present) should be also transported to the “sorted positions” - regardless if there is an entry or not!
If the internal program logic maintains a “lower right cell coordinate” and sorting only applies the display properties to the cells for the active cells as they were before, it should extend the display properties of the rightmost column actually treated during the sorting process and if there is a leftover, it should extend the display properties from the rightmost active cell of each row to its very end. This is analogous to what happens after “Insert Column to the right”. This is consistent with the general result of extending a spreadsheet: Display properties are always propagated from the left to the right and from top to bottom: Insert Column left inserts a new column with properties  inherited from the old column left of the insertion column, Insert Column right inserts a new column with the display properties derived from the current column. Insert row above and row below behave this way also following the top to bottom rule.

Steps to Reproduce:
1.Make a table in LO Calc with some column by which the entries will be rearranged after sorting by this column
2.Highlight one row which will change its place after applying Sort to some part of the spreadsheet.
3.Mark a part in this spreadsheet to be sorted, the item which is highlighted with the background color will change its place must be in the selection.
4. Sort the selected items.

Actual Results:
4. Sorted table is ok, regarding only the input in the cells. But highlights are broken after sorting. Same applies to other cell display features like boldnes, italics, font, size, slant, color and maybe more if they exist.

Expected Results:
I expect that the rows of a spreadsheet maintain their properties after sorting, even in the part right to the most rightmost cell of the to be sorted part or the whole spreadsheet.


Reproducible: Always


User Profile Reset: Yes



Additional Info: