Hi Steve, it seems that NumberPreparer (in trunk) doesn't completely ignore the start/end values when numberStyle == NONE. See line 116: if (first.getLeftStart() > first.getLeftEnd() || first.getRightStart() > first.getRightEnd()) initial = Math.max(initial, rightStart); else if (rightStart > 0) initial = Math.min(initial, rightStart); In normal processing, the fields are 0 when style is NONE, but NumberRangeTest.java sets them to -1 and this really produces different bit streams in some cases, e.g. when iter == 306 the following test case is generated: [0,O,9,7,O,7,5, 1,B,8,2,O,3,5, 2,O,1,1,N,-1,-1] and the patch numbers-v0.patch causes a test failure. Attached version 1 of the patch solves this issue, but I think the problem should be fixed in the preparer and the test should be adapted? Gerd