The generator used to build the PDF in question is putting in an extra character at the end of every dictionary. The character nul or char code zero is the character that is causing the issue. When we are parsing an <<>> dictionary the nul i picked up as an element in the hash and throws of the even number of elements that would normally make up the name value pairs. This is technically a malformed PDF but it's pretty easy for us to fix.

I've added a quick fix to our object parser which should be OK but a full qa run will needed for this change.

Marking as fixed.

Seems like I have the same problem in newer versions (tested 6.2.2 and 6.3.3).

Only happens with some PDFs.

Aug 04, 2020 7:19:32 AM org.icepdf.core.pobjects.Page init
WARNUNG: Error initializing Page.
java.lang.ClassCastException: org.icepdf.core.pobjects.Stream cannot be cast to org.icepdf.core.pobjects.graphics.images.ImageStream
at org.icepdf.core.util.content.AbstractContentParser.consume_Do(AbstractContentParser.java:605)
at org.icepdf.core.util.content.OContentParser.parse(OContentParser.java:295)
at org.icepdf.core.pobjects.Page.init(Page.java:436)
at org.icepdf.ri.common.views.AbstractPageViewComponent$PageImageCaptureTask.call(AbstractPageViewComponent.java:413)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)