[Libreoffice-bugs] [Bug 134684] New: Conditional Colour Formatting in CALC becomes inconsistent as table columns are deleted

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=134684

            Bug ID: 134684
           Summary: Conditional Colour Formatting in CALC becomes
                    inconsistent as table columns are deleted
           Product: LibreOffice
           Version: 6.3.6.2 release
          Hardware: All
                OS: Windows (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: that.man.colin at gmail.com

Description:
Insertion and deletion of columns with conditional colour scale formatting
doesn’t create a consistent colour rendition. As inserted columns are deleted,
the colours sometimes appear to reflect the maximum values that were ever seen
in the “table” depending upon the order in which the data columns are erased.
When the table is reduced to only 1 column – in this instance the original
column, the colours don’t seem to reflect the range of numbers remaining.

Attached is a simple example spreadsheet.

The column deletions are destructive so the second reference table L11;N17 has
been created out of the “line of fire” to illustrate the variations. I have
experimented with deleting and inserting new cells/columns as opposed to
deleting and undoing the action and this produces almost random adjustments to
the editable Conditional Formatting table – inspection reveals numerous
overlapping schemes which seem to be created by the moving and insertion events
but not removed by the deletions. Selecting and copying the “reference” table
onto the G1;I7 table after it has been damaged by deletion and re-insertion
also doesn’t replicate the colour scheme correctly. Saving and then reloading
the file whilst the colour scales are “damaged” then appears to inconsistently
restore colour scaling to G1;I7 in a vague representation of reality.

Steps to Reproduce:
Create a simple “pulldown” sequence of numbers from 1-7 in column G.

Select and conditionally format the range with the default 3 colour scheme.

Select the column and insert a column after this table’s column – a new column
H.

Observe that both the cell content format and the conditional formatting is
copied to the new “implied” table of seven cells from the left column G.

If the new column is inserted before the source column then the formatting is
replicated from the column to the left of the insert point – The former column
F.

xxxxxxx Herein lies one procedural question – should the format replication be
created from the selected or “source” reference ie column G being the right
column? - For me, it seems more logical to consider the before/after
relationship to the source column rather than simply default from the left - as
the source column is more likely to be providing the inspiration for the
insert.xxxxxxx

Having inserted the new column, “pulldown” the values 8-14 and observe the new
colour rendition.

Now insert a new column between G & H (it matters not which is the “reference”
column – the formatting will always be copied from the left or column G).

Now “pulldown” the values 15-21 in empty column H and observe the new colour
rendition.

Select and delete the values in column H and observe the new colour rendition –
seems consistent.

Undo the deletion and observe the colour rendition.

Select and delete the values in column I and observe the unchanged colour
rendition - seems inconsistent.

Delete Column I observe the colour rendition – what should be consistent?

Delete Column H observe the colour rendition - what should be consistent?

Undo the two column deletions – I am at a loss for words to describe what just
happened All the "undone" elements became one colour and the original column
was even more corrupt.

The second table G11:I17 was created by repeating the original process to
accurately reflect the expected colour scheme. It was not a simple copy/paste
of the original table.

Actual Results:
The colour formatting doesn't represent the range of numbers present in the
sample. It appears to "remember" what may once have been the range of numbers.
Saving and reloading almost solved the issue but the colours did not recreate
the original condition before the errors occurred.

Expected Results:
Consistently colour the data that is present in the sample - not what once may
have been.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:

Version: 6.3.6.2 (x64)
Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: sv-SE (en_GB); UI-Language: en-GB
Calc: threaded

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200709/b40bd8d0/attachment.htm>