| Summary: | DataFormatter Fractions for Whole Numbers | ||
|---|---|---|---|
| Product: | POI | Reporter: | Robert Kish <robert_kish> |
| Component: | POI Overall | Assignee: | POI Developers List <dev> |
| Status: | RESOLVED LATER | ||
| Severity: | normal | CC: | robert_kish |
| Priority: | P2 | ||
| Version: | 3.8-FINAL | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
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. (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. |
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.