Created attachment 13472 [details] out3.pdf In investigating the PDF/PCL speed differences, I've tried to change the way gx_image_cached_char works in the presence of the clist. This has shown up a problem that exists already in the code, and exhibits as a banding/non-banding difference. gs -sDEVICE=bitrgbtags -o out.bit -r300 -dMaxBitmap=1000 out3.pdf and gs -sDEVICE=bitrgbtags -o out.bit -r300 -dMaxBitmap=400000000 out3.pdf give renderings that differ in that the bottom pixel row of the descender of the 'g' is missed out. Stepping through the code, I see that we have a rectangular clip path that runs from 673 to 705 (a height of 32). We attempt to output the 'g' as a set of bits with y=685 and h=21 - implying that the last row of pixels *should* be clipped. If we watch in the clist reader, the gx_image_fill_masked call is being given a clipping path which goes from 1792 to 10240 - i.e. from 7 to 40, a height of 33.
Ok, I now understand why this happens. A clipping path is put into the clist. The path in the clist is correct. It is played back by filling that path into a clipping accumulator. It's a rectangle that extends precisely from a pixel boundary up a whole number of pixels. The antidropout code for horizontal edges causes an extra line to be put in at the top of the rectangle, thus extending it upwards. I might be tempted to look for a fix in the scan converter, were it not for the fact that I'm about to replace it.
The new scan converter gets this wrong too, though arguably it's in agreement with Acrobats handling of zero width regions. I will need to ponder this some more. Taking this bug back from Ray.
This bug appears to be fixed because clist and non-clist invocations produce identical results. These results look similar to the raster image produced by Acrobat.
I can confirm that we get identical results now. Closing. Thanks Peter.