<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Sorting in LO Calc Messes Background Colors of Rows"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=126678">126678</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Sorting in LO Calc Messes Background Colors of Rows
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>5.1.1.3 release
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Calc
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>adalbert.hanssen@gmx.de
</td>
</tr></table>
<p>
<div>
<pre>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:</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>