Bug 694837

Summary:	**** Warning: File has insufficient data for an image.
Product:	Ghostscript	Reporter:	Marcos H. Woehrmann <marcos.woehrmann>
Component:	PDF Interpreter	Assignee:	Henry Stiles <henry.stiles>
Status:	NOTIFIED FIXED
Severity:	normal
Priority:	P1
Version:	9.10
Hardware:	PC
OS:	All
Customer:	580	Word Size:	---

Description Marcos H. Woehrmann 2013-12-06 17:22:23 UTC

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.

Comment 2 Ken Sharp 2013-12-17 02:06:18 UTC

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.

Comment 3 Henry Stiles 2014-01-03 15:32:23 UTC

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.

Comment 4 Henry Stiles 2014-01-08 10:14:18 UTC

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.

Comment 5 Henry Stiles 2014-02-16 18:09:43 UTC

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).