Description: CALC options permit the identification and finding of "ad hoc" data labels by associating text in a preceding cell as a label. Having found the associated data it is intended that summation may be performed. Firstly, it doesn't perform that function when the data is in a row contiguous with the label Secondly, it permits empty spaces immediately following the column label but not a gap in the column's data. The second scenario may be appropriate as nobody is likely to want an "infinite" column - it just seems inconsistent to permit a an infinite number of leading empty cells. Steps to Reproduce: With the attached sheet:- Observe the formulae in A1 & A2 Observe that A2 is Zero Select C4:C15 and move the cells one column right Observe that Berlin comes to life and London fades into oblivion Undo SelectE2:O2 and move the cells to insert the first value into the gap in London's Data Observe the correct change to London's total at A1, the resurrection of Berlin's fortunes AND the gap of eleven empty cells in the Berlin column Undo Reselect E2:O2 and move to D3 Again, Berlin is "in play" and London is unaffected by the change What should happen if London has data below and adjacent to the label? Actual Results: Missing row summation Expected Results: Positive summation Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 175562 [details] Screen Dump and Example .ods
(In reply to Colin from comment #0) > CALC options permit the identification and finding of "ad hoc" data labels > by associating text in a preceding cell as a label. And that's about the worst idea implemented just because Excel had that feature (which it meanwhile also deprecated). Prefer not to use it. It's non-deterministic in more than one way. Use defined label ranges instead, Sheet -> Named Ranges and Expressions... -> Labels... > Firstly, it doesn't perform that function when the data is in a row > contiguous with the label It depends.. whether there's other rows labelling data or not. > Secondly, it permits empty spaces immediately following the column label but > not a gap in the column's data. The second scenario may be appropriate as > nobody is likely to want an "infinite" column - it just seems inconsistent > to permit a an infinite number of leading empty cells. It's not infinite, there's optionally one additional descriptive (may be empty) row after the label. It *appears* to be infinite if you're inserting rows above and the data range was already used the formula using it keeps its value (because internally the resulting range of 'Berlin' just happens to be a cell range that gets adjusted like any other range), but if re-entered it will not. > Reselect E2:O2 and move to D3 > Again, Berlin is "in play" and London is unaffected by the change > What should happen if London has data below and adjacent to the label? Exactly. In this constellation the "automatic" labelling can't magically determine that London *could* (or could not) be a row label, it hence sticks to the column label as usually data is in columns. A row label is only assumed if other row labels (i.e. text cells) are following. The automatic labelling feature is as bad as it gets and probably won't be further worked on. At best we should remove it from the Options page. Btw, please don't 7zip attachments into a container, one has to download and extract instead of simply being able to view files temporarily downloaded from the browser. Specifically with .ods and .png there's also ~0 space gain as both formats are already compressed.
(In reply to Eike Rathke from comment #2) > > Btw, please don't 7zip attachments into a container, one has to download and > extract instead of simply being able to view files temporarily downloaded > from the browser. Specifically with .ods and .png there's also ~0 space gain > as both formats are already compressed. Apologies, I hadn't considered it to be a space-saving operation, merely a manner in which multiple files could be uploaded in one hit. Not questioning your call, firefox allows me to open an archive and view the contents without the need to download, well not to the download folder anyway - it ends up in the AppData Temp folder so I can either retrieve it permanently or allow it to gently fade away. Consequently, I didn't realise it could be an issue.