Corrupt PDF Files

Okay. So all is good and my PDF files are streaming great. Funny thing is, some of the files are coming back as currupt. When I hit them directly using just a path, they are not corrupt. Does anyone have any ideas to what might cause this?

Are you using Reader or Writer rather than InputStream or OutputStream?
Are you using String or char[] rather than byte[]?
Are you ever converting between byte and String or char?
Are you using a mime-type that represents text (so that maybe your browser is doing one of the above)?
[ August 29, 2002: Message edited by: Dave Landers ]

Thanks for your quick reply. To answer your questions...
Q1) Are you using Reader or Writer rather than InputStream or OutputStream?
A1) I'm using a FileInputStream
Q2) Are you using String or char[] rather than byte[]?
A2) I am using byte to read in the data
Q3) Are you ever converting between byte and String or char?
No.
Q4) Are you using a mime-type that represents text (so that maybe your browser is doing one of the above)?
A4) Yes.
Keep this in mind. This streamer does work with many of the PDF files. But it doesn't work with all of them.
Here is my code.. see what you think...

/**
 * Stream the PDF directly to the browser
 * Creation date: (7/11/2002 9:55:40 AM)
 * @param path java.lang.String
 */
public void dispatchPDF(String pdfFileToDispatch, HttpServletResponse response)
    throws FileNotFoundException, IOException {
    File file = null;
    try {
        ServletOutputStream outStream = response.getOutputStream();
        //MIME type of pdf doc    
        response.setContentType("application/pdf");
        EnvironmentDataBeanSingleton envBean =
            EnvironmentDataBeanSingleton.getInstance();
        //
        //Using this header, you indecate that the content should be opened separately
        //(not actually in the browser) and that it should not be displayed automatically
        //but rather upon some further action by the user.
        //
        //response.setHeader("Content-disposition", "attachment; filename=" + pdfFileToDispatch);
        //attachment - since we don't want to open it in the browser
        //but with Adobe Acrobat, and set the default file name to use.
        //URL url = new URL(fileURL);
        file = new File(pdfFileToDispatch);
        //System.out.println("FILE PATH IS = " + file.getAbsoluteFile());
        FileInputStream fis = new FileInputStream(file);
        //BufferedInputStream bis = new BufferedInputStream(url.openStream());
        BufferedInputStream bis = new BufferedInputStream(fis);
        BufferedOutputStream bos = new BufferedOutputStream(outStream);
        byte[] buffer = new byte[2048];
        int bytesRead;
        //Simple read/write loop
        while (-1 != (bytesRead = bis.read(buffer, 0, buffer.length))) {
            bos.write(buffer, 0, bytesRead);
        }
    }
    catch (FileNotFoundException fnfe) {
        System.out.println("File was expected to be at " + file.getAbsoluteFile());
        throw new FileNotFoundException();
    }
    catch (Exception e) {
        System.out.println("Exception thrown when streaming " + file.getAbsoluteFile());
    }
}

At first glance, that looks OK to me.
Other things I'd probably check...
Try with other browsers - what I'm thinking here is I have seen IE ignore content type in favor of the file extension ".pdf" on the end of the URL. annoying.
Make sure the rest of your servlet program is not writing things to the output stream that may disrupt the output (setting headers or whatever).
Write a java program to connect to that servlet and dump the retrieved stream back to a file - then you can compare the files and see where the problem is - is it truncated or is is the data changing or what else. Might give you a clue what to look for.
Good luck - chances are when you are done you will either cry "Doh!" or you will have learned something really useful.

Good idea about writing the file back out and comparing. Will do.
-Dale

The BufferedOutputStream seems a bit redundant (you do some buffering yourself), but does it help if you flush() it?

Okay, so here's the deal. It seems that the file is being truncated. Streaming the file back to another file to do a compare worked great! Terrific idea! I'm about 389 bytes short. It seems those last bytes are being lost. Any ideas in how to avoid this?

Originally posted by David Weitzman:
The BufferedOutputStream seems a bit redundant (you do some buffering yourself), but does it help if you flush() it?

Hmm.. yeah. I think you're right. It might be redundant. Which method might be more useful to keep?
Dale

I would just write strait to outStream. And did you try flush()ing?

Originally posted by David Weitzman:
I would just write strait to outStream. And did you try flush()ing?

Thanks.. Flushing out the buffer did the trick. Thanks so much!
Dale

Glad that worked, but I'm wondering why the buffer didn't flush automatically when it was closed (or when it was finalized).

The servlet container would have flushed the response.getOutputStream() stream probably just by closing it). But it would not know about leftover bytes sitting in the BufferedOutputStream that wrapped it. Those are the ones that got lost.
Flushing that buffer gets those bytes to the response stream where the servlet container can flush them to the client.

Threads like this make me so proud to be a participant in JavaRanch!

Hi,

I think you can try a utility called Advanced PDF Repair to repair your PDF file. It works rather well for my corrupt PDF files. Its web address is http://www.datanumen.com/apdfr/