[poppler] Bug in JBIG2Stream

[Albert Astals Cid]

A Dimecres, 10 de juny de 2009, David Benjamin va escriure:
> 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.

Seems okaish, let me pass it trough the regression testing (3 or 4 days not 
counting the weekend) to see if it fixes/breaks other pdf.

Thanks for the contribution :-)

Albert

>
>
> 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.