pdfmark_SP() does not verify if the clipping path written to the output PDF file needs updating. As a consequence, Form XObjects displayed with /SP pdfmark are clipped incorrectly if the clipping path changed since the preceding text/ line/ fill operation. With the attached sample, the output PDF should display a full circle on the first page and a quarter of a circle on the 2nd one, but it does the opposite.
Created attachment 785 [details] Short file to reproduce the problem.
I would appriciate a suggested patch for this. See gdevpdfb.c,v 1.22 ln 125-132 as a prototype. Also it may need pdf_viewer_state_from_imager_state - see an example in gdevpdtt.c,v 1.84 ln 2029. See also gdevpdtt.c,v 1.84 ln 186 - 195.
downgrading priority
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-August/005653.html http://ghostscript.com/pipermail/gs-cvs/2005-August/005654.html
I reopen this bug because the commited patch contains 2 errors. (I) If, when executing a /SP pdfmark, the current path is not empty, then that path gets stroked. Suggested fix: add a "newpath" before the "-2 -2 moveto". (II) The patch adds some code that is supposed to stop the artificial stroke (the one used to sync the clipping path) to be written to the output PDF. However, it fails to do so in many cases. (No effects in the raster, the stroke being off-page, but a file size increase.) Details: a) "gx_cpath_outer_box(pcpath, &clip_box);" Except when the clipping path has been modified by the PostScript code, its bounding rectangle includes (0,0) (in device coords). b) "-2 -2 moveto ..." The bounding box of the stroke is a rectangle that includes (-2,-2) (device-space coordinates), thus its upper-right corner has x,y >= -2. c) "bbox_expansion_x = ... + fixed_1 * 2; stroke_bbox.q.x += bbox_expansion_x;" Similar for y. The stroke's bounding box is "inflated" by at least 2 device units. Thus, its upper-right corner has x,y >= -2 + 2 = 0. d) (a) & (c) imply that the intersection of the stroke's inflated bounding box and the clip box is often non-empty (includes at least the device origin). As a consequence, the stroke gets written into the output file. Suggested fix: move the stroke farther away from the origin, for example "-9 -9 moveto" instead of "-2 -2 moveto". Note: this fixes the problem when the clippath is the default or one "simple enough". I don't know what happens if the clipping path was constructed using "curveto"s that have the contol points far away from the actual curve.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-September/005729.html