This bug has been spun out of an example discovered while testing bug 690620. When the clip region is set to a path that encloses no area, filling a rectangle that overlays this area can still cause the page to be marked. This is demonstrated in clipbug.ps, a file that I will attach in a moment.
Created attachment 5791 [details] clipbug.ps The test file creates 7 different clip regions, and rectangle fills behind them. The clip regions are defined by using the clip operator to restrict the current clipping region to the current path, where the paths differ in each case, as follows: 1) moveto 2) moveto, close 3) moveto, lineto (same position), close 4) moveto, lineto (horizontal change), close 5) moveto, lineto (vertical change), close 6) moveto, lineto (diagonal change), close 7) moveto, lineto (horizontal change), lineto (vertical change), lineto (retrace steps), close All of these result in paths that enclose zero area. Acrobat marks the page for 4,5,6,7. Ghostscript for 4,6,7. The GS code currently does not mark the page if the 'inner bbox' of the clipping path is a single point (or invalid). The inner bbox should not be a single point for 5, so I suspect the difference here lies elsewhere.
Reassigning to new email address.
I confirm that Acrobat marks 4,5,6,7. Ghostscript normally marks 4,5,6,7 bit can drop some lines at special resolutions. At 300 dpi it marks 4,6,7; at 72, 144, and 216 dpi it marks 4,6.
Created attachment 20406 [details] clipbug.ps with labels
Created attachment 20407 [details] clipbug.pdf - a matching hand-made PDF file.