tree 135c044735c41ae1b883ad9ec90efaa3b5d74dee parent 28f4cd52c9a9f3aa0fb62b1cd8b6a7b4da4e8fc8 author Ken Sharp 1715698840 +0100 committer Ken Sharp 1715699233 +0100 Graphics library - clipping fix When applying a rectangular clip, and the current clip is also a rectangle, there is an optimisation which checks the two rectangles to see if the new clip is the same as (or I believe larger) than the current clip. In that case we can quickly ignore it because the clip cannot get bigger. However there's a slight problem, the comparison is done using the fill adjustment rules, and checks that the current clip is *larger* than the new one. I believe this should be larger or equal. Currently this is causing a small but significant number of files to clip incorrectly with pdfwrite. The problem arises at 72 dpi when a clip is exactly the same as the current clip. The fill adjustment causes a number of the co-ordinates of the new clip to be the same as the old clip, so we don't recognise the clips as identical. We then send this to pdfwrite. The pdfwrite device 'undoes' the existing clip and then sets the new clip. But the existing clip is the page, so we grestore all the way back to the page level before writing the new clip. This can end up undoing state that should be preserved. This *only* happens at low resolution, but it does cause problems. Altering the test to >= and <= correctly identifies the clips as being the same and we get the same output at low resolution as we do when creating a PDF file at high resolution. No rendering devices show any differences at all.