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.

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.