| Summary: | /SP pdfmark inside /BP-/EP pdfmark pair for XObject re-use | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Alexander Grahn <a.grahn> |
| Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | P4 | ||
| Version: | 8.62 | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: |
patch for gdevpdfm.c to solve the /SP inside /BP-/EP pdfmarks issue
patch for gdevpdfm.c to solve the /SP and /BP-/EP nested inside /BP-/EP pdfmarks issue patch for nested form XObject pdfmarks |
||
Created attachment 6828 [details]
patch for gdevpdfm.c to solve the /SP inside /BP-/EP pdfmarks issue
The proposed patch adds an /XObject resource dictionary to the stream dictionary of an XObject in case it references other XObjects in its content stream.
Now, a valid XObject will be created by a /BP-/EP pair of pdfmarks, if other XObjects are inserted in its content using the /SP pdfmark.
Further improvement is possible. Currently, the /BP-/EP pdfmarks /always/ add a reference of the XObject to be created into the /XObject resources dictionary of the page stream, irrespective of whether it has been or will ever be used in the page content stream. Perhaps, it would better to let the /SP pdfmark make this addition to the current substream.
Created attachment 6834 [details] patch for gdevpdfm.c to solve the /SP and /BP-/EP nested inside /BP-/EP pdfmarks issue This is a refined patch which allows nesting, to arbitrary depth, of /SP as well as of /BP-/EP pdfmarks into other Form XObject definitions (/BP-/EP pdfmarks). Also fixes bug 689653. Created attachment 6858 [details] patch for nested form XObject pdfmarks The patch has been updated once more. Also fixes bug 689653. Patch (finally!) adopted in commit 3d544d51c3e1d63a2fd115dac23255c966ba0e Apologies for the length of time its taken to review and adopt this. |
Hi, If one tries to re-use existing XObjects, that were created using /BP & /EP pdfmarks, within another XObject to be created using a /BP-/EP pdfmark pair, the resulting container XObject lacks the /XObject <<...>> entry in its /Resources dictionary. Consequently, when loading the PDF into Adobe Reader, an error message such as ``Could not find the XObject named '/R9'.'' is issued. While Ghostscript-8.62 produces invalid PDF from the example PS code below, PDF written by Acrobat Distiller is ok. Alex Cherepanov on comp.lang.postscript encouraged me to re-file this bug report. -- Alexander Example PS code. Two XObjects, one black `+' and one gray `x', are created using /BP-/EP pdfmark pairs. They are re-used in another XObject with name {container} which is created by /SP pdfmarks nested into a /BP-/EP pdfmark. Since the child XObjects are associated with optional content groups (OCGs) they can be hidden and made visible in the `Layers' panel of Adobe Reader. %!PS-Adobe-1.0 %%BoundingBox: 0 0 100 100 mark {Catalog} << /OCProperties << /OCGs [{ocg1} {ocg2}] /D <</ON [{ocg1} {ocg2}] /Order [{ocg1} {ocg2}]>> >> >> /PUT pdfmark %OCGs mark /_objdef {ocg1} /type/dict /OBJ pdfmark mark {ocg1} <</Type/OCG /Name (black cross)>> /PUT pdfmark mark /_objdef {ocg2} /type/dict /OBJ pdfmark mark {ocg2} <</Type/OCG /Name (gray cross)>> /PUT pdfmark 0 0 moveto %black `+' gsave mark /_objdef {cross1} /BBox [0 0 100 100] /BP pdfmark 50 0 moveto 50 100 lineto stroke 0 50 moveto 100 50 lineto stroke mark /EP pdfmark mark {cross1} <</OC {ocg1}>> /PUT pdfmark grestore %gray `x' gsave mark /_objdef {cross2} /BBox [0 0 100 100] /BP pdfmark 0.5 setgray 0 0 moveto 100 100 lineto stroke 0 100 moveto 100 0 lineto stroke mark /EP pdfmark mark {cross2} <</OC {ocg2}>> /PUT pdfmark grestore %container XObject gsave mark /_objdef {container} /BBox [0 0 100 100] /BP pdfmark mark {cross1} /SP pdfmark mark {cross2} /SP pdfmark mark /EP pdfmark grestore %draw container mark {container} /SP pdfmark