Created attachment 99310 [details] Example spreadsheet Problem description: 3 hashmarks appear instead of the actual number. The number is 11 so there is plenty of space for it so there should be no hashmarks. When I doubleclick on the number, then the hashmarks disappear. Then I doubleclick on the row separator on the left side to change the row's height the hashmarks come back. I recorded a video of the behaviour. Also if I change the number to 10, 12 or 11.001 there is no problem. Update: I just realized this problem only happens if the number in D3 is the same as the number in C3. Steps to reproduce: 1. Open the attached spreadsheet. 2. Check why D3 is ###. 3. Current behavior: Hashmarks instead of number. Expected behavior: Number, no hashmark. Operating System: Linux (Other) Version: 4.2.3.3 release
Created attachment 99311 [details] Desktop recording of the problem.
Hi Adam, thanks for reporting. I can reproduce with: Win7x64 Version: 4.2.3.3 Build ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0 I think it is in relation the style: Excel_BuiltIn_Comma _-* #.##0,00 _F_t_-;-* #.##0,00 _F_t_-;_-* -?? _F_t_-;_-@_- there four formats without any condition, so only positive; negative; zero values, could be applied, and with several defined spaces (_ followed by a character). Giving enough width to the cell shows the value (about 6cm), seems as if the * is producing the issue repeating the space after it, needing a wider cell. Deleting the * in the style, seems to solved the issue.
This is still an issue in 4.3.0.4.
Maybe this thread can be helpful about the situation with the use of the '*' in the format. http://lists.freedesktop.org/archives/libreoffice/2012-April/030381.html
That thread is too technical for me. Why did you set this bug to unconfirmed? If the value of C3 is the same as D3 then D3 becomes ###. Why?
Hello Adam, m.a.riosv, Quotation marks seem to miss in the Currency format. Instead of this format: In your spreadsheet, select D3. Right clic on it. In the contextual menu, choose Format cells... In the format code window, instead of: _-* #.##0,00 _F_t_-;-* #.##0,00 _F_t_-;_-* -?? _F_t_-;_-@_- correct it by: _-* #.##0,00 _F_t_-;-* #.##0,00 _F_t_-;_-* "-"?? _F_t_-;_-@_- With this change, cell width has to be reduced to 1.7 cm before you find again these marks. Does it solve this issue for you? Jacques
Created attachment 104247 [details] your example corrected the way I indicate Hi Adam, I changed the format as I indicated it in my previous comment. Perhaps this will be easier to try so. Tell us if that solve your issue. regards, Jacques
Jacques: I don't understand what you're doing. If you remove the part that's causing the bug then of course there will be no bug. That doesn't mean the bug is fixed does it?...
From my point of view, it's rather an import/fileopen issue rather than formatting issue. @Adam, wasn't that XLS file created with Microsoft Excel 97 ?
I don't know how it was created. :(
(In reply to comment #9) > > wasn't that XLS file created with Microsoft Excel 97 ? Probably yes, I opened file in hex editor and found this string "Microsoft Excel 97-Tabelle Biff8"
MS Excel Viewer shows the number 11 in D3 cell LibO shows ### in D3 cell confirmed using LibO 4.3.3 and recente 4.5.0 daily build under Win8.1x64 status NEW hardware ALL
Confirmed in version 5.0.2.2 (Ubuntu 15.10).
bug persists even in a recent 5.1.0.0 alpha daily build I cheked older releases too and I found that the bug is not present in 3.5.7.2 and appeared first in 3.6.0.4 so it's a regression of the 3.6.x branch and needs bibisecting I add Calc expert to CC list.
It is the combination of "_-" and "* " in the number format and font. Handling of * that fills the cell with the following character, in this case spaces, between two strings was implemented somewhen along as mentioned. Here the problem seems to be the _- that reserves the space of a hyphen / minus sign without displaying it. If one widens column D the value 11.00 is eventually displayed. Also if C3 is emptied then D3 is displayed. Also changing font or size helps, note that Arial is not available on Linux systems and falls back to another font. Seems that calculation of the available space is confused in this combination.
Additional finding, ### are displayed if column D is narrower than column C, the value 11.00 in D3 is also displayed if column C is shrunk. It might be that the output width of the text in C3 is cached and reused for D3, which would be wrong if the * repeat code was used.
Which actually explains why it doesn't happen for other values than 11 in C3 ...
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b94eccd1d1bb7e1a849e6a024acf84b7a7c12ed3 Resolves: tdf#78897 do not cache/reuse a repeat-filled string It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/19198 for 5-0
Hurray :)
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b959b6ba7c3a7385e353ea2fa617b82e177960a0&h=libreoffice-5-0 Resolves: tdf#78897 do not cache/reuse a repeat-filled string It will be available in 5.0.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fix VERIFIED in 5.1.0.0.alpha1+ Build ID: f830600ece806ec365a4839e79afabe183c5e36d TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-06_22:49:09 Locale: it-IT (it_IT) thanks Heike, I new you were the right man to ping!!!
My name is Eike, but anyway.. ;-)
Eike, great work! Maybe you'd like to take a look at my other fine bug :) https://bugs.documentfoundation.org/show_bug.cgi?id=82226
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e634c893fbe388ad3978aaaa00db7fe0df280078 tdf#78897: sc_pdf_export: Add unittest It will be available in 7.3.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.