Bug 149428 - Formatting of number AFTER the decimal point not saved in .ods
Summary: Formatting of number AFTER the decimal point not saved in .ods
Status: RESOLVED DUPLICATE of bug 96723
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2022-06-02 00:31 UTC by r435g391b823-comp176456@yahoo.com.au
Modified: 2022-06-12 20:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
openGL info (288.72 KB, image/jpeg)
2022-06-02 00:34 UTC, r435g391b823-comp176456@yahoo.com.au
Details

Note You need to log in before you can comment on or make changes to this bug.
Description r435g391b823-comp176456@yahoo.com.au 2022-06-02 00:31:53 UTC
Description:
Cell Number Format is lost when sheet is saved and closed/reopened, or reloaded.
The formatting that is lost are any user defined formats for the numbers AFTER the decimal point. when the format is changed it works, then when the sheet is reloaded it is munged. 
Eg format #,##0.0000_i0000_i00    correctly formats a number to 0.0001 5299 00
But after closing/reloading becomes #,##0.0000000000"  " and the number formatting is lost.
Doesn't affect .xlsx and .xlsm format sheets, but I lose all my buttons and macros in those save file format versions.
Updated libreOffice to latest 7.3.3.2 release and still occurs as described above.


Steps to Reproduce:
1.Place a number in a cell with 2 or more digits After the decimal point, eg 0.0000158932. I use mainly 8, 10 and 12 digits after the dot.
2. Change formatting of that cell to user defined format which formats the numbers AFTER the decimal point, eg #,##0.0000_i000_i000. Any formatting such as _i or  _M  or " " or \-  or \ , anything that makes the numbers more readable.     
Eg #,##0.0000_i0000_i00, which correctly formats a number to 0.0001 5299 00
3. Save the sheet, and either close/reopen or FileMenu->Reload it.
4. The cell becomes a long string of unformatted digits again, and the user defined format string has changed, eg #,##0.0000_i0000_i00 becomes #,##0.0000000000"  " and the number formatting is lost. The number of spaces now appearing in double-quote marks at the end of the format string bears some relationship to the formatting/spaces in the working format before saving/closing.


Actual Results:
Cell format changes and numbers are no longer formatted as they were.

Expected Results:
Formatting of numbers after the decimal point should be retained.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 7.3.3.2 (x64) / LibreOffice Community
Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-AU (en_AU); UI: en-GB
Calc: threaded
Comment 1 r435g391b823-comp176456@yahoo.com.au 2022-06-02 00:34:10 UTC
Created attachment 180533 [details]
openGL info

the new bug page says to check open gl info, so i have and include the info.
Comment 2 Rafael Lima 2022-06-02 13:53:25 UTC
Reproducible in LO 7.3.3.

The format code is changed after saving. For instance, I used #,##0_i000_i000 and it worked fine. But after saving, closing and reopening the file, the format code changed to #,000000000"  "

The format code informed by the user should have been saved as intended, so changing this to NEW.


Version: 7.3.3.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.3~rc2-0ubuntu0.21.10.1~lo1
Calc: threaded

Also reproducible in:
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 9d50307b2e1fd26d415539d3ed8624c7a449e45b
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded
Comment 3 Laurent Balland 2022-06-03 08:12:17 UTC
Actually, there is no way to save such specific format in ODF. You can only save it in XLSX.
ODF save the number of decimals (either 0, or blank (?) or empty place (#)), plus some text after the number, but it has no information if text is placed inside decimal part.

How ODF save format, if text is inserted in integer part: 00" "00" "00" "00" "00
   <number:number number:decimal-places="0" number:min-decimal-places="0" number:min-integer-digits="10">
    <number:embedded-text number:position="8"> </number:embedded-text>
    <number:embedded-text number:position="6"> </number:embedded-text>
    <number:embedded-text number:position="4"> </number:embedded-text>
    <number:embedded-text number:position="2"> </number:embedded-text>
   </number:number>

If text is inserted in decimal part: 0.00" "00" "00" "00" "00
   <number:number number:decimal-places="10" number:min-decimal-places="10" number:min-integer-digits="1"/>
   <number:text>    </number:text>
number position is lost and restored as 0.0000000000"    "
Could we store a negative value of "position" to indicate it concerns decimal part?

number:position is defined here: https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#attribute-number_position
as position is defined as an integer, it could get negative value.

Add Eike in CC.
Eike, do you think it is reasonably feasible?
Comment 4 Eike Rathke 2022-06-07 10:55:26 UTC
Negative positions to indicate right of decimal separator might be feasible.
Nevertheless ODF will need to be adapted, because the current text explicitly mentions "starts with 1 and is counted by digits from right to left in the integer part of a number" and so on. For position 0 text would be inserted before the decimal separator then and -1 before the first digit after the decimal separator, and probably appended if resulting position would be after number:decimal-places.
Comment 5 Eike Rathke 2022-06-07 10:57:38 UTC
Btw, I think I already saw this and it might be a duplicate of another bug, but I didn't find anything on a first glance.
Comment 6 Laurent Balland 2022-06-12 20:27:17 UTC

*** This bug has been marked as a duplicate of bug 96723 ***