[poppler] Bug in JBIG2Stream
davidben at MIT.EDU
Tue Jun 9 20:19:05 PDT 2009
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.
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  (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, 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.)
>  http://www.adobe.com/products/acrcapture/agentpack/index.html
>  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...
Size: 13969 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/poppler/attachments/20090609/39393765/attachment.bin
More information about the poppler