| Summary: | Wrong clipping path with /SP pdfmark | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | SaGS <sags5495> |
| Component: | PDF Writer | Assignee: | leonardo <leonardo> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | Keywords: | bountiable |
| Priority: | P3 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: | Short file to reproduce the problem. | ||
|
Description
SaGS
2004-07-05 10:26:16 UTC
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.
|