Status of 686779, /ioerror in --token--

Bug 686779, "/ioerror in --token--" has been reported by a customer
#131 on 2003-03-18.
http://bugs.ghostscript.com/show_bug.cgi?id=686779
There was an extensive discussion about problem on the mailing lists
but the sides don't come to any conclusion. The bug is still open.

In short, JAWS PDF creator generates a FlateEncode'd context stream
(from a 0-length input stream) which zlib doesn't accept. Different
interpreters handle this stream differently.

JAWS:           Accepts and decompresses to empty file
Acrobat Reader: Accepts, because it silently stops reading buggy
                 streams. This fact can be easily tested by overwriting
                 any stream in a PDF file with random garbage.
PostScript 3:   Fails, because PDF to PS converter apparently leaves
                 the stream intact, but Adobe PS rejects this stream on
                 PostScript level. The stream extracted from PDF
                 cannot be read by Adobe interpreters.
Ghostscript:    Fails with ioerror.

I've posted a patch that traps errors during reading of the content
stream issuing a warning.
http://www.ghostscript.com/pipermail/gs-code-review/2003-May/003820.html
I have no opinion whether zlib should accept the stream but the patch is
bug-compatible with Acrobat Reader.

Shailesh <[email protected]> analyzed the
patch and wrote

 > ... stream also declares that the data block length is zero and
 > therefore it is up to the decompression routine to return the
 > appropriate result.

 > The zlib routines regard a zero length data block to be a error and
 > therefore return the appropriate error message back to Ghostscript.
 > I could not find anywhere in the zlib documentation to say that zero
 > length data blocks are definitely not allowed so it may be their code
 > needs updating.

Here's the full message:
http://www.ghostscript.com/pipermail/gs-code-review/2003-May/003823.html

Igor concluded that the patch needs more work.
http://www.ghostscript.com/pipermail/gs-code-review/2003-May/003824.html
http://www.ghostscript.com/pipermail/gs-code-review/2003-May/003826.html

There were several ideas how to improve the patch.
(1) Fix zlib. Even if the patch is accepted, it will take a while
     before the old version goes away.
(2) Pre-analyze the stream on PS level and return an empty stream
     without calling zlib. This looks like a kludge, nor does it help
     when the stream is really broken.
(3) Pre-analyze the stream on C level.

I still think that my patch is a better solution because:
(1) it is simple
(2) it behaves similar to Acrobat Reader for PDF
(3) it leaves PostScript level to be bug-compatible with Adobe.
     I just wish we were so compatible in other respects.

Regards,
Alex