Description: In a previous version of libreoffice, I used formatting code #,##0"." for displaying 123.45 as "123." In the current version (6.1.5-3+deb10u7), when this formatting is set for a cell, an input of 123.45, after ENTER, is displayed in the edit field as 12345. In other words, this format causes the decimal point in the input to be lost. Steps to Reproduce: 0. Decimal separator is set to '.' 1. Format cell as #,##0"." 2. Enter 123.45 Actual Results: 12345 displayed in input/edit field, cell displayed as 12,345 Expected Results: Input/edit field contains 123.45, cell content formatted as 123. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.1.5.2 Build ID: 1:6.1.5-3+deb10u7 CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: x11; Locale: en-US (en_US.utf8); Calc: group threaded
Reproduced with 7.0.6: Version: 7.0.6.2 (x64) Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded @Joel: Do you remember which previous version that worked for you? Or which old Debian version (Debian 9?) with the LibreOffice that worked? This helps the QA people to decide when this bug possibly happened.
@Ming Thank you. The previous libreoffice version is 5.2.7-1+deb9u11. (I found this in /var/log/dpkg.log*)
(In reply to joel roth from comment #2) > @Ming Thank you. The previous libreoffice version is 5.2.7-1+deb9u11. Thanks for the quick feedback. However when I tried with 5.2.7 on Windows 10, I can still reproduce the wrong behavior: Version: 5.2.7.2 (x64) Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10 CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; Locale: zh-CN (zh_CN); Calc: group This is the oldest version I have installed. For completeness, also reproducible with 7.2/master daily build: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 18e5e948dd66e41f17b0a63bf631d98aee84a03b CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded (In reply to joel roth from comment #0) > Actual Results: > 12345 displayed in input/edit field, cell displayed as 12,345 The actual result for me is slightly different (all three versions -- 5.2, 7.0, and master), I get: 12345 displayed in the formula bar, 12,345. displayed in cell. Note the extra dot at the end for the cell display. > Expected Results: > Input/edit field contains 123.45, cell content formatted as 123.
The confusion here is the literal string that equals the decimal separator. Those literal strings are skipped when scanning the input, like 00"x"00"y"00 will accept an input of 12x34y56 as the number 123456. Seems we need to exempt the decimal separator character. But then again, only if one of those is present.. Taking.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3561978410579c5222889eb7dce68f917b550334 Resolves: tdf#142186 Accept 123.45 fractional input on weird formats like 0"." It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/c/core/+/115277 for 7-1
(In reply to Commit Notification from comment #5) > Eike Rathke committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 3561978410579c5222889eb7dce68f917b550334 > > Resolves: tdf#142186 Accept 123.45 fractional input on weird formats like > 0"." Thanks for the quick fix, Eike! I have a question though -- you call format code like 0"." weird, but what is the normal way to specify format for "I want the decimal point always displayed, but zero decimal places"? I would think it's a reasonable and common enough requirement, and I tried format code #,###. which does not work. Reading online help at https://help.libreoffice.org/7.2/en-US/text/shared/01/05020301.html didn't give me any enlightenment either. Or is it proper to use #,###"." here, just don't put "." after format code 0?
Weird in the sense that displaying a literal character that happens to equal the decimal separator without any decimals following is rather unusual (or I've not seen it in the wild). And will not work as intended if it was assigned using the default (not a fixed) number format locale and the document is opened in a locale that uses a different decimal separator character, it would still display the literal "." of course. Note that using #,###. after save/reload becomes #,###"." because it is saved as <number:number-style style:name="N111"> <number:number number:decimal-places="0" number:min-decimal-places="0" number:min-integer-digits="0" number:grouping="true"/> <number:text>.</number:text> </number:number-style> (note the <number:text>.</number:text>) as otherwise there is no distinction between number:decimal-places="0" number:min-decimal-places="0" with or without decimal separator. Out of interest: what does Excel display for #,###. and how does that survive a save/reload cycle?
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/88772bcf331152f24dde343ffe694c85fea8b6d3 Resolves: tdf#142186 Accept 123.45 fractional input on weird formats like 0"." It will be available in 7.1.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Solved. Verified in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: b238522ca121ca8f863fe4d3394ade088a65ad01 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e8b2849f2d336e903992ff7a3483364085594d12 tdf#142186: sc_ucalc: Add unittest It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.