The file forces our CCITTFax filter to fail and as a result we fall back trying to decode the image using all the available ccittfax variations. We'll have to come back to this issue one we move over the 12 monkies imaging code base.

I spent a half day looking at how we might integrate the library into the render core, we'll at least for CCITTFax processing. One of the strange things about the CCITTFax images that are embedded in PDF documents is that the image stream is generally just the data stream and as a result we have generate the correct TIFF header data and add it to the data stream. Once this is done the tiff data can be read by any one of the CCITTfax implementations.

We have had good luck with the JAI implementation but we do have a few corner cases it can't handle and given the libraries licensing and closed source nature we are at a bit of dead end. The twelve monkeys library seems to offer similar functionality to JAI but similarly there are still a few corner cases which the library can't load. One additionally issue with twelve monkeys is that is depends on JDK 7 which is a problem for our JDK 5 library. JDK 7 dependency can be mitigated if we make the decoding calls via ImageIO allowing the dynamic loading of the the imaging libraries. On a side note any further work on our imaging library should probably also leverage the ImageIO architecture.

From my experiments our org.icepdf.core.pobjects.filters.CCITTFax class would be the best place to integrated the ImageIO calls to load the twelve monkeys API for CCITTFax. Further analysis and testing is need for JPEG and TIFF support integration.

 img = ImageIO.read(new MemoryCacheImageInputStream(in));

or

 
           TIFFImageReaderSpi SPI = new TIFFImageReaderSpi();
           TIFFImageReader reader = SPI.createReaderInstance(null);
           reader.setInput(new MemoryCacheImageInputStream(in));

Marking as fixed