The customer reports but I have not been able to duplicate that the following command line: gswin32c -dBATCH -dNOPAUSE -q -dColorConversionStrategy=/LeaveColorUnchanged \ -dGrayImageDownsampleType=/Bicubic -dCompatibilityLevel=1.4 \ -sDEVICE=pdfwrite -dMonoImageResolution=100 \ -dMonoImageFilter=/JBIG2Encode -dPDFSETTINGS=/screen \ -sOutputFile=out.pdf test.pdf Produces the following warnings: **** Warning: File has insufficient data for an image. **** Warning: File has insufficient data for an image. **** Warning: File has insufficient data for an image. **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> PDFScanLib v1.2.2 in Adobe Acrobat 10.1.4 <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. When the -dMonoImageResolution=100 is replaced with -dMonoImageResolution=200 the warnings go away.
This 'looks like' a bug in the JBIG2 encoder, or possibly pdfwrite is using it in an unexpected way. Because of the filter chain it is possible that we can call the various stream writing routines with no actual bytes of data to emit. All the other stream processing routines happily ignore this, but the jbig2 encoder regards it as an error. In s_jbig2encode_process() : long in_size = pr->limit - pr->ptr; ... if (in_size > 0) { ... ... } if (last && state->outbuf == NULL) { ... ... } if (state->outbuf != NULL) { ... ... } /* something went wrong above */ return ERRC; So if there is no data buffered up to process and we don't have any lingering data, then its an error. If I change that to return 0 instead, the file runs to completion. A simpler command line which doesn't use the highly confusing -dPDFSETTINGS switch (note that -dGrayImageDownsampleType has no effect on Monochrome images) : -dCompatibilityLevel=1.4 -dDownsampleMonoImages=true -sDEVICE=pdfwrite -dMonoImageResolution=100 -dMonoImageFilter=/JBIG2Encode -sOutputFile=/temp/out.pdf I think Henry owns decoders at the moment so I'm assigning this one to him.
Ugh... the release code 9.10 had the dreaded revision/float bug so I had to use 1.5 for compatibility level. Anyway, I agree with Ken's analysis and I guess this is the natural patch for the code as it is written: diff --git a/gs/base/sjbig2_luratech.c b/gs/base/sjbig2_luratech.c index bd0d965..ea9fc8b 100644 --- a/gs/base/sjbig2_luratech.c +++ b/gs/base/sjbig2_luratech.c @@ -573,7 +573,11 @@ s_jbig2encode_process(stream_state * ss, stream_cursor_read * pr, else return EOFC; /* all done */ } - /* something went wrong above */ + /* no data. */ + if (in_size == 0 && !last) + return 0; + + /* something went wrong above. */ return ERRC; } Now to figure out how to test it.
Partial fix here: commit b2ecdbba02eac6fa19866bd18c83ece7cdd4074d Author: Henry Stiles <henry.stiles@artifex.com> Date: Wed Jan 8 10:57:46 2014 -0700 Possible fix for 694837. Allow the luratech jbig2 encoder to process 0 input without error like all other streams encoders. Analysis by Ken Sharp. Marcos' observation is not really cleared up. I would expect to see 0 byte input for 200 dpi as well, so we'll leave this open for a bit.
Forgot to follow up on this one. We'll call this fixed with the commit in comment #4. Note, this bug can only be reproduced with the Luratech decoder. Presumably that is why Marcos did not see it (comment #1).