Description: If I give fractions in the lines and I use the SUM(B1:B10) it skips the first line, but only and only if I use fractions. If I use whole numbers, it works perfect. Steps to Reproduce: 1. Give the following numbers in separate lines: 7,5 8,25 8,25 8,58 8,25 8,87 9,22 8,12 7,07 7,75 ----- 2. Use the SUM(B1:B10) or SUM(A1:A10). Also try to remark the area to omit skipping any of those numbers: 3. Result: it forgets to add the 7,5 to the whole SUM... Actual Results: 74,36 Expected Results: 81,86 Reproducible: Always User Profile Reset: No Additional Info: Windows 11 Pro, 22H2 Build: 22621.1702 Windows Feature Experience Pack 1000.22641.1000.0
Created attachment 187636 [details] Screenshot of the problem SUM gives 74,36 instead of 81,86 !!!
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 187638 [details] Sample ODS file that contains the bug Sample ODS file that contains the bug.
mmm, something weird is happening with the '7,5' value. If I type 7,5 again, then it works, if I copy B1 to B2, then the sum is 66,11 @Eike, @Mike, I thought you might be interested in this issue
The file has *text* in B1, so no bug here: SUM ignores all non-numerical cells. Use View->Value Highlighting to see. However, some issues here. 1. Comment 0 tells: > Give the following numbers in separate lines: > > 7,5 > ... This could result in the seen problem, *if* the first cell (whole row?) was pre-formatted as *text*, in which case, it is perfectly correct that anything you type there later would be treated as text, and not converted to numbers. But the file has B1 (and A1, C1) formatted as Standard. The question is: was the file re-formatted after the entry (and in that case, it is OK that the already present text was kept as text), or was there some *unknown* condition (a real problem?) that the entered data wasn't converted to number? 2. Why doesn't it show an apostrophe ahead of the text in this case, when it's obviously possible to treat it as a number, so the apostrophe is needed? (At least no leading apostrophe here in 7.5.4.1.)
Cell B1 is a rich text cell where each character is formatted differently: <text:p><text:span text:style-name="T1">7</text:span><text:span text:style-name="T2">,</text:span><text:span text:style-name="T3">5</text:span></text:p> These when editing are never inspected for a possible numeric content as rich text is not converted to numeric, hence no leading ' apostrophe in the Input Line. The attribution styles used are <style:style style:name="T1" style:family="text"> <style:text-properties style:use-window-font-color="true" style:font-name="Calibri" fo:font-size="12pt" fo:font-weight="bold" style:letter-kerning="false" fo:language="hu" fo:country="HU" style:language-asian="en" style:country-asian="US" style:language-complex="ar" style:country-complex="SA" style:font-name-asian="Calibri1" style:font-name-complex="Calibri1" style:font-size-asian="11pt" style:font-size-complex="12pt"/> </style:style> <style:style style:name="T2" style:family="text"> <style:text-properties style:use-window-font-color="true" style:font-name="Calibri" fo:font-size="12pt" fo:font-weight="bold" style:letter-kerning="false" style:language-asian="en" style:country-asian="US" style:language-complex="ar" style:country-complex="SA" style:font-name-asian="Calibri1" style:font-name-complex="Calibri1" style:font-size-asian="11pt" style:font-size-complex="12pt" fo:language="de" fo:country="DE"/> </style:style> <style:style style:name="T3" style:family="text"> <style:text-properties style:use-window-font-color="true" style:font-name="Calibri" fo:font-size="12pt" fo:font-weight="bold" style:letter-kerning="false" style:language-asian="en" style:country-asian="US" style:language-complex="ar" style:country-complex="SA" style:font-name-asian="Calibri1" style:font-name-complex="Calibri1" style:font-size-asian="11pt" style:font-size-complex="12pt" fo:language="hu" fo:country="HU"/> </style:style> i.e. they differ in language/country attribution where apparently the comma alone was pasted with / edited as a fo:language="de" fo:country="DE" (German Germany) attribution. So far not a bug at all. Just a question how that cell content was created..
Thanks - it's good to know (and news to me :)) (In reply to Eike Rathke from comment #6) > So far not a bug at all. Just a question how that cell content was created.. ... and a usability problem, because it's not easy to see this, and no way to understand why does this cell (mis)behave like that, not showing apostrophe, allowing to convert to number by adding a trailing space, etc. IMO, looks like we need more whistles^w indicators (similar to the arrow showing collapsed comment, but in this case, hinting that the cell is "rich-formatted"). Something for UX...