Fix: Resolving a Shading didn't create a reusable stream for the shading

data; since the data was then read at unpredictable times, the shading or
other constructs in the PDF file could read incorrect data.

git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@238 a1074d23-0009-0410-80fe-cf8c14f379e6

1 files changed, 8 insertions, 2 deletions

diff --git a/gs/lib/pdf_draw.ps b/gs/lib/pdf_draw.ps
index 84df5cd5c..734005644 100644
--- a/gs/lib/pdf_draw.ps
+++ b/gs/lib/pdf_draw.ps
@@ -124,12 +124,16 @@ currentdict /tfopdict undef
 
 /resolveshading {	% <shname> resolveshading <shading>
   Page /Shading rget {
+    PDFfile fileposition exch
     mark exch {
       oforce //shrdict 2 index .knownget { exec } if
     } forall .dicttomark
     dup /ShadingType get 4 ge {
-      dup dup true resolvestream /DataSource exch put
-    } if
+      dup dup true resolvestream
+		% Make a reusable stream so that the shading doesn't
+		% reposition PDFfile at unexpected times.
+      /ReusableStreamDecode filter /DataSource exch put
+    } if exch PDFfile exch setfileposition
   } {
     null
   } ifelse
@@ -485,11 +489,13 @@ end
 	% color and color space before running the PaintProc.
 	% There's no harm in doing this for colored patterns,
 	% so for simplicity, we always do it.
+  PDFfile fileposition 3 1 roll
   q
   null sc1 null SC1
   exch false resolvestream pdfopdict .pdfruncontext
   Q
   DEBUG { (%End PaintProc) = flush } if
+  PDFfile exch setfileposition
 } bdef
 
 /resolvepattern {	% <patternstreamdict> resolvepattern <patterndict>