Current revision of gswin32c (10319) fails with "Can't refill scanner input buffer!" running gswin32c.exe ps3cet\14-03.PS This bug is NOT caused by my recent patch to the scanner, rev. 10312. The function scan_handle_refill() assumes that reading of a stream will either return some data or an error code. This may not be the case if a filter consumes the input but doesn't generate any output, for instance, skips headers. When the following lines /* No more data available, but no exception. How can this be? */ lprintf("Can't refill scanner input buffer!"); return_error(e_Fatal); are replaced with return 0; the file runs normally.
I noticed this as well but figured it was just CET weirdness since the file works if you redirect input from STDIN: bin/gs -< ps3cet/14-03.PS OTOH, gs8.70 worked even with the command line given in Comment #0. You'll probably have it fixed before I find it, but I'm running a search-svn-revs to isolate the change.
Looks like this broke in r9989, which seems possible based on the log message: r9989 | alexcher | 2009-08-13 12:04:34 -0700 (Thu, 13 Aug 2009) | 13 lines In hex form of eexec stream, break out of reading loop and try to interpret the accumulated data when a whitespace character is encountered. Skip whitespace characters when the control returns to /eexecDecode filter. Bug 689577. This wasn't caught during regression testing since all the CET files are run with redirection from stdin.
Created attachment 5798 [details] Proposed patch Ghostscript streams are tricky. I'd like to get Ray's opinion before committing this patch. There's nothing wrong when a filter returns an empty buffer. It just means that a filter in the pipeline consumed all input but didn't generate any output. This can happen when the filter skips big headers.
Created attachment 5834 [details] better patch This is an improved patch that doesn't propagate non-standard return code 2 to the filters and documents the code. eexecDecode filter has to terminate processing of the input stream when it encounters a space character and return the control to the interpreter. Modern Adobe applications don't add padding after eexec. If the interpreter calls the same filter again, the space characters should be skipped. When the stream is received from stdin, character by character, the input buffer has one character at a time. So the check for an initial space is not useful in this case.
*** Bug 691137 has been marked as a duplicate of this bug. ***
I have a 16 MB file (1.9 MB compressed) that gets this error with gs8.71 under Linux, and the "better patch" fixes it. I can post the file or email it if it will help testing.
The 'better patch' looks fine to me. Please commit (assuming it passes a local regression -- you've probably already done it).
Don't throw an error when a filter returns 0 bytes and a normal return code. This often happens with eexecDecode filter, which has to return the control to the interpreter after every space character since Adobe no longer adds zeros at the end of the encoded block. Document new return code 2 used by eexecDecode filter. The patch from the comment #4 has been committed as a rev. 10926. Regression testing shows no differences. William Bader, this issue is now resolved. Thank you for using and testing Ghostscript.