If the personalized numeric format #,99# is saved and applied in a spreadsheet, and the document is saved and reloaded, the format is no longer defined, and all the cells so formatted are now formatted as "standard". Thus displaying 0 and ,8 and ,88 and ,888 . . . . . as 0 and 0,8 and 0,88 and 0,888 respectively, instead of ,00 and ,80 and ,88 and ,888 as expected. If custom format #,999 did not exist before save, after restarting Libo it has been created. If such a custom format already exists, after restarting Libo it is not used by the cells formatted as #,99# Previously libreoffice consistently displayed this format correctly. Not sure when it stopped working as I haven't used this format much for a while, until I started using it intensively recently. The last version of Libreoffice used before the current version was 3.* This has been tested numerous times and the error ALWAYS occurs. The computer used has been rebooted many times between tests. This format is used to display numbers which may be percentages, or per thousand, in a more readable format. There is no easy workaround. Redoing the format on a large spreadsheet is very time consuming.
I use a period for my decimal point, and that is evident in the rest of this comment. Is there any reason to think that this could explain why my results differ from andréb's? Format code '#.99#' does display the values unhelpfully: .99 and .998 and .999 and .999 but (a) this differs from andréb's description, and (b) it seems right to me, seeing as '9' is a literal character inserted into the display. Format code '#.00#' gives the display that andréb asks for. I see this in both daily dbgutil repository version 2015-10-10 and 3.5.4.2 as delivered with debian-wheezy. So, andréb, can you confirm that you really mean 9's in the first paragraph of the bug description? If so, can you attach a workbook as it was left by a version of LibreOffice which displays it the way you want? Remember that attachments to a bug report are visible to the whole world, so do not include anything that you do not want the whole world to see. Thank you, andréb, for helping us to improve LibreOffice. I am setting bug status to NEEDINFO; please set it back to UNCONFIRMED when you reply. Terry.
Created attachment 119529 [details] spreadsheet showing problem
(In reply to Terrence Enger from comment #1) > I use a period for my decimal point, and that is evident in the rest > of this comment. Is there any reason to think that this could explain > why my results differ from andréb's? Thanks for your response. I hadn't thought of period/comma difference being related, but everything worked correctly in the (not very recent) past. > Format code '#.99#' does display the values unhelpfully: .99 and .998 > and .999 and .999 but > (a) this differs from andréb's description, and > (b) it seems right to me, seeing as '9' is a literal character > inserted into the display. Right, I wrote 9s instead of 0s. (Shouldn't write bug reports when exhausted.) > Format code '#.00#' gives the display that andréb asks for. I see > this in both daily dbgutil repository version 2015-10-10 and 3.5.4.2 > as delivered with debian-wheezy. #,00# works correctly for me in the session it is defined, but if I save and exit, the format is no longer defined when I reload the spreadsheet in question. Giving the other symptoms mentioned in the description. > So, andréb, can you confirm that you really mean 9's in the first > paragraph of the bug description? If so, can you attach a workbook as > it was left by a version of LibreOffice which displays it the way you > want? Remember that attachments to a bug report are visible to the > whole world, so do not include anything that you do not want the whole > world to see. > Terry. I added a new file showing the problem. Column A is using default format. Column B is same values, initially formatted as #,00# (english = #.00#) (No other personalized formats were added.) After saving, closing all open .ods files, and reloading the test file, Column B is formatted to automatically created format #,000 The #,00# format initially defined is gone. Note that this is somewhat different to the spreadsheet initially showing the problem. In that spreadsheet, on reloading, the format was set to default values, not #,000 Maybe because I have many personalized formats defined. But that spreadsheet contains a lot of personal data.
I can not confirm with Version: 5.1.0.0.alpha1+ Build ID: 51df957e1a40d2f3511345c1600c05dd35f34b6b TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-10-19_04:22:32 Please could you test with dev version? http://dev-builds.libreoffice.org/daily/master/ Thank you Column B formatted as #,00# After saving, closing all open .ods files, and reloading the test file, Column B is formatted #,00#
@ andréb - please try with 5.0.2.2 or later with a fresh profile: https://wiki.documentfoundation.org/UserProfile
especially dates formats are lost when spreadsheet is reloaded
andréb, Thank you for the attachment. It makes it much easier to see what we are talking about. I have done some tests with daily dbgutil repository version 2015-11-13 ... (*) When I open the attachment, column B hass formatting code #.000, as you describe, and the displayed values correspond. (*) When I created a very similar spreadsheet from scratch with format code #.00#, the format code and the corresponding displayed values survived the several times that I saved and reloaded the file. LibreOfficeDev version 4.4.0.0.alpha2, however, applied format code #.### when it loaded my file. This is not quite exactly what happened to you, but it is pretty close. So, again the obvious "fix" is for you to try a recent version of LibreOffice. HTH, Terry.
Andréb, please test with dev version and let us know..
OK, when I have time, by this weekend
(In reply to raal from comment #8) > Andréb, please test with dev version and let us know.. Libo 5.0.3.2 works after save and reload now with format "#,00#" (in french) (equivalent to "#.00#" in english), but another regression makes it useless for me : The minimum window height was <= 4 cm (in Libo 4.4.6.3, from my distibution of Linux), now it is 14.5 cm. In order to use Libo with other applications (which is how I generally use it), I need to be able to use a window height of 10 cm (or less). I filed bug 96027 for that. Setting status to NEW since it already confirmed and (apparently) still valid for stable releases. Hopefully that is correct.
Wrong status - moving back to UNCONFIRMED.
(In reply to andréb from comment #10) > (In reply to raal from comment #8) > > Andréb, please test with dev version and let us know.. > > Libo 5.0.3.2 works after save and reload now with format "#,00#" (in french) > (equivalent to "#.00#" in english), So this bug can be closed > but another regression makes it useless > for me : > The minimum window height was <= 4 cm (in Libo 4.4.6.3, from my distibution > of Linux), now it is 14.5 cm. > In order to use Libo with other applications (which is how I generally use > it), I need to be able to use a window height of 10 cm (or less). > I filed bug 96027 for that. > > Setting status to NEW since it already confirmed and (apparently) still > valid for stable releases. Hopefully that is correct. Hello andreb, thanks for testing. I'm closing this bug, because as you tested the bug is resolved in newer version. For stable release we have BackportRequest:4.4 whiteboard tag, but before setting this tag, you should test 4.4.x dev version ( http://dev-builds.libreoffice.org/daily/libreoffice-4-4/ ) - maybe it's fixed here already. But as I see in release plan (https://wiki.documentfoundation.org/ReleasePlan/4.4 ), 4.4.7 is RC2 phase, so no new fixes expect.