Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.0
-
Fix Version/s: 6.3
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:any
-
Support Case References:Support Case 14253:- https://icesoft.my.salesforce.com/5000g00001orMCb?srPos=0&srKp=500
-
Salesforce Case Reference:
Description
The file in question is contains content stream encoded using the FlateDecode filter. ICEpdf currently relies on the java.util.ZipInflaterInputStream to handle the decompression. Unfortunately the ZipInflaterInputStream is chocking on this stream.
After quite a bit of tracing it became apparent that is was the last ZipInflaterInputStream.read call that was reporting the error. The only way that I could get all the needed content tokens was to set the buffer to 1 byte as a work around. The problem with he 1 byte buffer is that it isn't performant.
After quite a bit of tracing it became apparent that is was the last ZipInflaterInputStream.read call that was reporting the error. The only way that I could get all the needed content tokens was to set the buffer to 1 byte as a work around. The problem with he 1 byte buffer is that it isn't performant.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Suggesting work around for the time being.
Show
Patrick Corless
added a comment - Suggesting work around for the time being.
Reopening issue with the hope of finding a more performant work around.
Show
Patrick Corless
added a comment - Reopening issue with the hope of finding a more performant work around.
Re-opened this issue. There are a few open source zip libraries out there that could possible fix this issue and be a little quicker then the default java implementation.
Show
Patrick Corless
added a comment - Re-opened this issue. There are a few open source zip libraries out there that could possible fix this issue and be a little quicker then the default java implementation.
I've revisited this on request from a support customer. I've touched up the flate decode to check the stream length and adjust the buffer size appropriately. By default the decode will try and use a rather large 16 KB buffer and will fall back to 2 KB buffer if the stream is really small.
Show
Patrick Corless
added a comment - I've revisited this on request from a support customer. I've touched up the flate decode to check the stream length and adjust the buffer size appropriately. By default the decode will try and use a rather large 16 KB buffer and will fall back to 2 KB buffer if the stream is really small.
I've added the system property org.icepdf.core.flateDecode.bufferSize to allow users to set the default buffer size which ~16KB. For large file the buffer could be set higher to improve performance. But for this client they will have to set org.icepdf.core.flateDecode.bufferSize=1 for the the time being.