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