| Summary: | CALC evaluate Column or Row Labels only evaluates Columns - A tad erratically | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Colin <that.man.colin> |
| Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | Inherited From OOo | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Attachments: | Screen Dump and Example .ods | ||
|
Description
Colin
2021-10-06 12:00:43 UTC
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. |