Bug 697673

Summary:	Clist gets clip path wrong
Product:	Ghostscript	Reporter:	Robin Watts <robin.watts>
Component:	Graphics Library	Assignee:	Robin Watts <robin.watts>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	sphinx.pinastri
Priority:	P4
Version:	master
Hardware:	PC
OS:	Windows NT
Customer:		Word Size:	---
Attachments:	out3.pdf

Description Robin Watts 2017-03-17 06:32:43 UTC

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.

Comment 1 Robin Watts 2017-03-17 10:09:58 UTC

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.

Comment 2 Robin Watts 2017-03-17 10:53:33 UTC

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.

Comment 3 Peter Cherepanov 2020-12-27 19:01:25 UTC

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.

Comment 4 Robin Watts 2022-01-20 19:31:09 UTC

I can confirm that we get identical results now. Closing. Thanks Peter.