| Summary: | opdfread: Wrong graphics state when painting a Form XObject | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | SaGS <sags5495> |
| Component: | PS Writer | Assignee: | leonardo <leonardo> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: | Suggested patch. | ||
Created attachment 1671 [details]
Suggested patch.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-September/005716.html Many thanks to SaGS. |
The implementation for the "Do" PDF operator in the opdfread procset does not set up the graphics state as stated in the PDF Reference (for PDF1.6 it's in section 4.9 "Form XObjects", page 327). Specifically, it does not transform user space according to /Matrix and does not clip to the /BBox. ----- The specs also require the "Do" operator to save/restore the graphics state. The patch below does not do this because here the PDF producer is fixed (GS) and it generates PDF code in a particular way. All "Do"s are bracketed, together with a "cm", inside "q"/"Q", so an extra level of gsave/grestore is not needed. This extra level of gsave/ grestore would lower the nesting limit for Form XObjects. Each nesting level would use 3 elements on the gsave-stack out of the typical limit of 31: (1) one for the "q"/"Q" in "q ... cm /Rn Do Q"; (2) one implicit in the implementation of "Do"; (3) one because GS starts/ ends every content stream, in particular the Form XObject's content, with "q"/"Q". By excluding (2), we get 50% more nesting levels. Sample file: http://bugs.ghostscript.com/show_bug.cgi?id=687560#c1 (either modify to set XObjectNameStep to 1, or apply the patch in http://bugs.ghostscript.com/show_bug.cgi?id=687560#c19 )