This is a spin off from bug 694842. In order to do halftoning we build threshold tables. These are then used to map contone values to dithered values, such that if contone(x,y) < threshold(x,y), we set the pixel at (x,y). For an n pixel area, there are n+1 possible levels (ranging from 0 to n pixels set). As such we'd expect the threshold table to map roughly equal divisions of the source contone range into each level of dither. The existing code fails to do this. For a source range of 0..255 it divides the range into n 256/n sized blocks (for the middle cases) and two 512/n sized blocks (for the 0 and n cases). We should fix this. Also, we should check the behaviour of the code in the case where we are dithering with more than simple black and white.
Assigning to Michael, as requested.
Created attachment 20415 [details] Test case I don't know how to observe any effects of this in rendering. When the test case is rendered as: ~/ghostpdl/debugbin/gs -r1000 -o a.tiff -sDEVICE=tiffg4 a.ps it produced a few steps of a tint ramp. These steps occur due to internal rounding to 8 bit. The width of every step is about the same. IMHO Ghostscript works fine.