Description: Hello, I entered this number format description to display phone numbers: 0#" "##" "##" "##" "## When I reopen my document after saving, the description has changed to: #" "##" "##" "##" "#0 cordially Steps to Reproduce: 1. enter the description format 0#" "##" "##" "##" "## in a cell 2. save and close the document 3. reopen the calc Actual Results: the description format is transformed in #" "##" "##" "##" "#0 Expected Results: preserved the description Reproducible: Always User Profile Reset: No Additional Info:
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Sorry but what it's the sense of such format, '0' should be followed by zeroes not by #. Well may be looking for a way to get the number aligned to the left, with two numbers before the first space. But I think numbers format can't work in this way
(In reply to m.a.riosv from comment #2) > Sorry but what it's the sense of such format, '0' should be followed by > zeroes not by #. Well may be looking for a way to get the number aligned to > the left, with two numbers before the first space. But I think numbers > format can't work in this way Either the format is correct and reopening the file should display the same or it's incorrect and there should so error message when trying to save the formula, shouldn't it? Eike: thought you might be interested in this one.
Code pointers: https://opengrok.libreoffice.org/xref/core/svx/source/items/numfmtsh.cxx?r=4ffb036f#FillEntryList_Impl https://opengrok.libreoffice.org/xref/core/svx/source/items/numfmtsh.cxx?r=4ffb036f#FillEListWithUsD_Impl
Meanwhile the bug submitter found out that what he actually needed instead is " 0 " #" "##" "##" "##" "## The problem with the reported format is that it is ambiguous regarding the use of 0 and #. While it works in the number formatter when entered, it can't be stored as format description to ODF which results in <number:number-style style:name="N121"> <number:number number:decimal-places="0" loext:min-decimal-places="0" number:min-integer-digits="1"> <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> </number:number-style> Whereas " 0 " #" "##" "##" "##" "## is stored as <number:number-style style:name="N121"> <number:text> 0 </number:text> <number:number number:decimal-places="0" loext:min-decimal-places="0" number:min-integer-digits="0"> <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> </number:number-style>
(In reply to Julien Nabet from comment #3) > Either the format is correct and reopening the file should display the same > or it's incorrect and there should so error message when trying to save the > formula, shouldn't it? The number formatter is file format agnostic and should be. I'm not sure the original format code with its intention could even be described in ODF syntax. However, the minimal reproducer could be 0# which when reloaded is just 0 and stored as <number:number-style style:name="N121"> <number:number number:decimal-places="0" loext:min-decimal-places="0" number:min-integer-digits="1"/> </number:number-style> The intention of the format is to prepend a 0 if the number is one digit (except for the 0 case, but I'm not even sure if that is on purpose), but that's basically the same for the format code 00 except for the 0 case where it also displays 00. Which is stored as <number:number-style style:name="N121"> <number:number number:decimal-places="0" loext:min-decimal-places="0" number:min-integer-digits="2"/> </number:number-style>
(In reply to Eike Rathke from comment #6) > (In reply to Julien Nabet from comment #3) > ... > The number formatter is file format agnostic and should be. > ... I don't understand why but you're the Calc expert and I trust you. Should this one be a WONTFIX then?
Maybe the 0# format could be stored with a number:min-integer-digits="1" and loext:optional-integer-digits="1" (which would have to be implemented as a new loext namespace extension) or some such, and for 0#" "##" "##" "##" "## with a similar number:min-integer-digits="1" loext:optional-integer-digits="9". Not sure, needs investigation I don't have time for currently.
(In reply to Julien Nabet from comment #7) > (In reply to Eike Rathke from comment #6) > > The number formatter is file format agnostic and should be. > I don't understand why but you're the Calc expert and I trust you. Because the number formatter does not know anything about the target file format the number format will be stored in, storing to Excel formats for example simply will store the format code. Reading such format code also should not invalidate the format just because it could be stored in a different file format. Also, with the (more empirically determined) syntax of these format codes constructs are possible that can't be stored in all file formats. Then again, some formats are possible that can be stored in ODF but not in OOXML. Hence restricting the number formatter to a subset that all file formats know even if a format code otherwise is syntactically correct would not be a good approach. And furthermore error-prone because the format code syntax is really twisted..
I tested with: 0# " 0 " #" "##" "##" "##" "## 0#" "##" "##" "##" "## And this numbers remain as entered into the cells. Am I missing something or something have changed? Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
When dealing with large Calc (7.0.6.2 OR 7.1.3) sheets with many columns , I find this BUG BOTH ANNOYING and TIME CONSUMING. When using spreadsheets as a data source when writing reports, time and flow of work are disrupted when one has to RE-FORMAT a range of cells or cell, only to have it revert to its previous #### state a few seconds later, regardless of one of the format changing cells are selected or not.
Dear Fred, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
In Windows 10(x64), no problem at all.When I reopen the file it shows 0#" "##" "##" "##" "##.No changes.No producable in Windows 10(x64). Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d74344f6cae0cf1c12f08249c8f49be1374fb98f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-IN (en_IN); UI: en-US Calc: threaded
I repro Format Cell - Numbers - Format Code with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 81726f5af5fda25f0d92ffc8458d7f24eb16f408 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded