Bug 78897 - DISPLAY: Hashmarks instead of number with * repeat format code if the same number/format was displayed left of it in a wider column
Summary: DISPLAY: Hashmarks instead of number with * repeat format code if the same nu...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA target:5.1.0 target:5.0.3 target:...
Keywords: regression
Depends on:
Blocks:
 
Reported: 2014-05-19 09:09 UTC by Adam Niedling
Modified: 2021-11-18 11:52 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Example spreadsheet (11.00 KB, application/vnd.ms-excel)
2014-05-19 09:09 UTC, Adam Niedling
Details
Desktop recording of the problem. (305.29 KB, video/ogg)
2014-05-19 09:12 UTC, Adam Niedling
Details
your example corrected the way I indicate (19.00 KB, application/xls)
2014-08-07 21:37 UTC, Jacques Guilleron
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Niedling 2014-05-19 09:09:58 UTC
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
Comment 1 Adam Niedling 2014-05-19 09:12:21 UTC
Created attachment 99311 [details]
Desktop recording of the problem.
Comment 2 m_a_riosv 2014-05-20 00:11:08 UTC
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.
Comment 3 Adam Niedling 2014-08-06 08:25:59 UTC
This is still an issue in 4.3.0.4.
Comment 4 m_a_riosv 2014-08-06 09:21:21 UTC
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
Comment 5 Adam Niedling 2014-08-06 13:05:12 UTC
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?
Comment 6 Jacques Guilleron 2014-08-06 13:43:48 UTC
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
Comment 7 Jacques Guilleron 2014-08-07 21:37:59 UTC
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
Comment 8 Adam Niedling 2014-08-08 07:11:10 UTC
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?...
Comment 9 ign_christian 2014-08-08 08:44:49 UTC
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 ?
Comment 10 Adam Niedling 2014-08-11 07:30:34 UTC
I don't know how it was created. :(
Comment 11 raal 2014-09-09 14:40:02 UTC
(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"
Comment 12 tommy27 2014-11-23 16:59:03 UTC
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
Comment 13 Adam Niedling 2015-10-05 19:34:56 UTC
Confirmed in version 5.0.2.2 (Ubuntu 15.10).
Comment 14 tommy27 2015-10-06 04:03:25 UTC
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.
Comment 15 Eike Rathke 2015-10-06 12:33:11 UTC
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.
Comment 16 Eike Rathke 2015-10-06 12:40:44 UTC
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.
Comment 17 Eike Rathke 2015-10-06 12:44:12 UTC
Which actually explains why it doesn't happen for other values than 11 in C3 ...
Comment 18 Commit Notification 2015-10-06 14:12:59 UTC
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.
Comment 19 Eike Rathke 2015-10-06 14:29:05 UTC
Pending review https://gerrit.libreoffice.org/19198 for 5-0
Comment 20 Cor Nouws 2015-10-06 15:05:28 UTC
Hurray :)
Comment 21 Commit Notification 2015-10-07 08:01:35 UTC
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.
Comment 22 tommy27 2015-10-07 19:26:48 UTC
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!!!
Comment 23 Eike Rathke 2015-10-07 20:32:03 UTC
My name is Eike, but anyway.. ;-)
Comment 24 Adam Niedling 2015-10-07 20:43:30 UTC
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
Comment 25 Commit Notification 2021-11-18 11:52:48 UTC
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.