Bug 53150 - DataFormatter Fractions for Whole Numbers
Summary: DataFormatter Fractions for Whole Numbers
Status: RESOLVED LATER
Alias: None
Product: POI
Classification: Unclassified
Component: POI Overall (show other bugs)
Version: 3.8-FINAL
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-25 19:55 UTC by Robert Kish
Modified: 2013-08-14 21:08 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Kish 2012-04-25 19:55:29 UTC
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.
Comment 1 Nick Burch 2013-06-26 20:40:23 UTC
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.
Comment 2 Robert Kish 2013-08-14 21:08:22 UTC
(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.