Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


(no subject)

  • mtraut

    Thank you for providing the information.

    We can confirm the behavior and added a "fix" - i think this should be much the same as what PDFBox did. Simply catch the exception and go on.

    I didn't go into the zlib implementation and why this specific stream might deviate from the Java way of interpreting it. If someone has more information on the "why", please provide it...

    So far, overriding the "read" method in PDFInflaterOutputStream will fix this behavior.

    public int read(byte[] b, int off, int len) throws IOException {
        try {
            return super.read(b, off, len);
        } catch (EOFException e) {
            // this is a workaround for a bug when decoding a FlateFilter
            // stream where, after completely decoding, java zlib complains
            // about EOF - maybe someone should someday get into this
        } catch (ZipException e) {
            // now that we are already filtering exceptions...
        return -1;