After resolving bug 96822 in 5.2 master, under certain conditions, one cannot quickly decide if a cell contains number or string data type. Consider this:
1. In a new spreadsheet, enter a number (e.g. 1) to A1.
2. For A1, choose Format - Cells and select the "Text" category.
3. For A2 choose the same cell format.
4. Enter a number (e.g. 1) to A2.
The number in A1 has not been converted to text (as documented in ) and it appears as office:value-type="float" in the ODS file.
The number in A2 is of text data type and appears as office:value-type="string" in the ODS file.
However, both numbers are left-aligned and have the same formatting code, so it is hard to identify their types.
This issue could be solved by:
- reverting the patch for bug 96822,
- adding an immediate conversion to text when format is changed (e.g. Google Sheets performs such immediate conversion).
TESTING with Ubuntu 14.04 +
LO 126.96.36.199.alpha0+ (2016-02-24_23:58:47)
(In reply to Stanislav Horacek from comment #0)
> After resolving bug 96822 in 5.2 master, under certain conditions, one
> cannot quickly decide if a cell contains number or string data type.
> Consider this:
> 1. In a new spreadsheet, enter a number (e.g. 1) to A1.
> 2. For A1, choose Format - Cells and select the "Text" category.
> 3. For A2 choose the same cell format.
> 4. Enter a number (e.g. 1) to A2.
> The number in A1 has not been converted to text (as documented in ) and
> it appears as office:value-type="float" in the ODS file.
> The number in A2 is of text data type and appears as
> office:value-type="string" in the ODS file.
> However, both numbers are left-aligned and have the same formatting code, so
> it is hard to identify their types.
> This issue could be solved by:
> - reverting the patch for bug 96822,
> - adding an immediate conversion to text when format is changed (e.g. Google
> Sheets performs such immediate conversion).
Seems like a reasonable change (at least to discuss), so
Status -> NEW
Should this be categorized as an enhancement or a regular bug?
You can always see the kind of entries via toggle "value highlighting" (Ctrl+F8).
Never change content _automatically_ by changing a format. You might do it after a warning hint. Another solution would be a "hint" at the cell (like the green marks in Excel) which tells the user, that there is a number in a text formatted cell.
I would prefer to revert bug 96822, because staying right aligned indicates the user, that the action "format cell as text" does not do "convert content to text".
Yes, the highlighting is a good way to see the types (even if different colors are not as distinct as different alignments). And I would agree with the revert.
However, I am wondering: What are use cases for numbers in text format (but not converted to text)? And if they are useful, why don't we have two choices here - one for format and one for type? The current state when the format change to text preserves numbers, but causes that a new value entered in the cell will be text, is not too intuitive for me.
(In reply to Stanislav Horacek from comment #3)
> However, I am wondering: What are use cases for numbers in text format (but
> not converted to text)?
You have already calculations in the spreadsheet and want to add explanations which might start with =, so you click on column or row header and set format text.
And if they are useful, why don't we have two
> choices here - one for format and one for type? The current state when the
> format change to text preserves numbers, but causes that a new value entered
> in the cell will be text, is not too intuitive for me.
Yes, a UI feature to convert number content into text, which performs a real conversion, would be useful. If such exists, a wrong use of formatting would be less likely.
interesting discussion for UX on the behavior of numbers, text, conversion..
(In reply to Cor Nouws from comment #5)
> interesting discussion for UX on the behavior of numbers, text, conversion..
and also the idea to revert bug 96822
(In reply to Cor Nouws from comment #6)
> and also the idea to revert bug 96822
Actually not. AFAIR that's also what Excel does, doesn't it? Displaying numeric content left aligned if the cell is formatted to text.
As for "adding an immediate conversion to text when format is changed" of the original request: applying a display format NEVER changes the cell content, and if Google Sheets does it that's their problem. Such behavior is completely unexpected and makes absolutely no sense if you think further and consider the layers of cell style, conditional format and hard format, in which each a number format can be applied.
Reverting the "numeric cell content is left aligned if formatted to text" argument again leads to "there's no indicator that the cell format is text if the content is numeric and input of new assumed-to-be-numeric content would be converted to text". It's going in circles and likely cell hints would be the best solution (which could be used for other scenarios like mismatching data in columns as well).
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still reproducible in 5.4.1 and in:
Build ID: 141fe1c5e7fbf67a083b34e49e19b6ea78a0eb2b
this point was discussed plenty times?
1. to take the alignment of cell content as a 'type indicator' is a weak approach / bad path as it could be manually overwritten.
2. it is almost a question of faith, one party defends that changes by the user should not have any harmful effects on existing constructions, but accepts that errors or 'irritations' will occur later, the other side thinks that an action by the user - also a formatting - is a declaration of intent to which he expects a reaction. And this immediately, not 'sometime later' when he has long forgotten what he reformatted, when and why, or never knew about it in a table from someone else.
3. I'm of the second opinion, if a user does damage with a format change he should see it immediately and still has 'ctrl-z' to help him out. if the damage occurs outside of his view he should be warned with a note, this should also be done with the current behaviour if later on - when evaluating the format change by changing the value - consequences in remote areas occur.
4. Capitalized 'NEVER' and 'consider other layers' are statements, but not arguments. From a programmer's point of view there are certainly arguments for the current procedure, from a user's point of view it is 'suboptimal'. The wish to have a program / table / sheet reacting to user actions in an way intuitively understandable to a user, even a 'simple-minded-user' is an argument. (i've lost weeks! with similar weak behaviour in excel, late evaluation of formats and 'hidden' exotic formattings not 'checkable' by the user, one can say i hate such things.)
5. Marking cells as what they are formatted to would be very helpful, regardless of the basic idea one belongs to, a clear marking if format and content do not match would be very good ... a detailed analysis of what a cell is formatted as, what it was formatted as when the content was entered, what it is currently evaluated as, and what would change with a 'touch' ... probably goes beyond the scope of a clearly arranged UI ...???
just my two cents,