[poppler] Bug in JBIG2Stream

[David Benjamin]

On further consideration, I believe getPos() is the wrong function to 
call (and is implemented wrong anyway). I believe the newly attached 
patch is more correct.

(Although, it doesn't look like JBIG2Stream::getPos is ever called anyway.)

I'm not sure why it bothers to subclass FilterStream though.


David Benjamin

On 06/07/2009 08:46 PM, David Benjamin wrote:
> So, I've been tracking down a bug in JBIG2Stream. It fails to render
> PDFs at [1] (second column) by misdetecting segments of incorrect length
> (and then eats up useful bytes at line 1445). JBIG2Stream appears to
> bypass FilterStream::str and uses it's own curStr[2], so getPos() is
> wrong at the beginning.
>
> Attached is a (trivial) patch to fix this. I'm not entirely sure if this
> is the "correct" thing to do here; the current setup feels pretty iffy
> anyway, but I get the feeling getPos() should not suddenly jump in the
> middle of a stream? I don't really know poppler's code, so I'm not sure
> what guarantees are Stream/FilterStream supposed to provide to users or
> if they're exported API in the first place.
>
> (At least internally in JBIG2Stream the only non-error-reporting use of
> getPos is the segment-length-detection bit.)
>
> [1] http://www.adobe.com/products/acrcapture/agentpack/index.html
>
> [2] It seems to want to swap the stream out temporarily at reset()...
> I'm not sure why; I'm unfamiliar with JBIG2.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-jbig2stream-getpos.diff
Type: text/x-patch
Size: 13969 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/poppler/attachments/20090609/39393765/attachment.bin