53150
2012-04-25 19:55:29 +0000
DataFormatter Fractions for Whole Numbers
2013-08-14 21:08:22 +0000
1
1
1
Unclassified
POI
POI Overall
3.8-FINAL
PC
Windows XP
RESOLVED
LATER
P2
normal
---
1
robert_kish
dev
robert_kish
0
oldest_to_newest
158438
0
robert_kish
2012-04-25 19:55:29 +0000
There are two issues with formatting fractions with a numerator value of 0 - For example, format 1.0 as a fraction yields with 1 digit numerator and denominators yields "1 1/9".
1.
This junit patch (to TestDataFormatter.java:testFractions) demonstrates the issue:
assertEquals("1 0/9", dfUS.formatRawCellContents(1.0, -1, "# #/#"));
I believe the solution to the following is:
In org.apache.poi.ss.usermodel.DataFormatter$FractionFormat, near line 1009:
for(int i2 = (int)(Math.pow(10, fractParts[1].length())- 1d); i2 > 0; i2--){
That loop's test should be i2 >= 0.
Was numerator meant to be abbreviated as num, instead of neum?
2. In Excel 2003, 1.0 with a format of "# #/#" gets written as "1 " (the fraction's digits are replaced by spaces and no / is written). I would expect some kind of emulateCsv support to handle this if it's decided that the solution to step #1 above is to print fractions as 0/d.
168086
1
apache
2013-06-26 20:40:23 +0000
I've just tested with r1497023, and the formatting now works the same as in excel for a whole number and "# #/#", so it looks like some of the recent fraction format fixes have solved this.
169450
2
robert_kish
2013-08-14 21:08:22 +0000
(In reply to Nick Burch from comment #1)
> I've just tested with r1497023, and the formatting now works the same as in
> excel for a whole number and "# #/#", so it looks like some of the recent
> fraction format fixes have solved this.
I've just tested with 3.10-beta1. The calculations, for the most part, are better. (See https://issues.apache.org/bugzilla/show_bug.cgi?id=55419)
The FractionFormat class, that implements the fractions logic, is now documented as not handling the Excel's spacing. While not ideal, because the solution itself is quite difficult, it's a good start.
It's more important for the numeric portion to be more correct, than the whitespace to be valid. I'm OK with how this was handled.