GNOME Bugzilla – Bug 315018
Fractions match number of digits in denominator, but lose the denominator.
Last modified: 2006-04-06 16:32:27 UTC
Windows version, 1.5.5-rc1 1. Type 1/13 in A1 Where did it go? 2. Select A1, press F2 A1 looks like 4 spaces.
Created attachment 51654 [details] fraction.gnumeric Open attached file, follow instructions
COnfirmed on Linux too. Note 1/13, 1/14, 1/15 etc disappears but 1/12 does not.
Yes, I think 1/12 is interpreted as a date.
So the problem is that 1/13 is recognized as a date and we then try to render it as #/#. Of course in that case it becomes 0/# which appears as blank (which denominator should we choose?) If we format as ##/## 1/13 reappears. Similarly for 1/102 which disappears for both #/# and ##/## but reappears for ###/###. Personally I think 0 ought to be rendered as 0/9 for #/# and 0/99 for ##/##
I think that Jody's fix to 144112 should remove the initial problem of 1/13 disappearing, but we should still fix the "blank" rendering of a fraction that is 0.
Andreas: agreed. Special attention is needed when the fraction rounds to zero (but the value isn't zero) and "render zeroes as blank" is active.
I've committed something to avoid rendering a blank. Unfortunately it's not entirely correct. We now match 0/13 to the format '? ??/??' note that this contains no references to the denominator. When attempting to render it we end up with 0/1. We need to change the logic of how we match to be able to construct a matching fmt rather than just matching against existing regexps. We also currently lose leading zeros for something like 012/0124
Matching got rewritten a while back. I just fixed two rendering bugs related to this so we show 0/1. Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.