Fix: If a 'stream' operator was followed by whitespace before the EOL, then

the fileposition was not at the start of the data. Add logic to allow for
this and also add a pdfformaterror if the EOL was a <cr> without a <lf>.
Fixes SourceForge bug 567612 for Artifex customer #1.

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

1 files changed, 14 insertions, 1 deletions

diff --git a/gs/lib/pdf_base.ps b/gs/lib/pdf_base.ps
index d9cf6f91f..8c5861d1e 100644
--- a/gs/lib/pdf_base.ps
+++ b/gs/lib/pdf_base.ps
@@ -494,15 +494,28 @@ pdfdict begin
 % especially since the PDF 1.2 specification states flatly that the only
 % legal terminators following the 'stream' keyword are \n or \r\n, both of
 % which are properly skipped and discarded by the token operator.
+% Unfortunately, this doesn't account for other whitespace characters that
+% may have preceded the EOL, such as spaces or tabs. Thus we back up one
+% character and scan until we find the \n terminator.
 /stream {	% <dict> stream <modified_dict>
   dup /F known dup PDFsource PDFfile eq or {
     not {
       dup /File PDFfile put
+      % make sure that we are just past the EOL \n character
+      PDFfile dup fileposition 1 sub setfileposition	% back up one
+      { PDFfile read pop dup 13 eq {
+	  % If there had been a \n, token would have advanced over it
+	  % thus, if the terminator was \r, we have a format error!
+	  (   **** PDF format error: stream operator not terminated by valid EOL.\n) pdfformaterror
+	  pop exit	% fileposition is OK (just past the \r).
+	} if 
+	10 eq { exit } if
+      } loop	% scan past \n
       dup /FilePosition PDFfile fileposition put
       DEBUG { (%FilePosition: ) print dup /FilePosition get == } if
     } if
     PDFfile fileposition 1 index /Length oget add
-      PDFfile exch setfileposition
+    PDFfile exch setfileposition
   } {
     pop
 	% We're already reading from a stream, which we can't reposition.