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. _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
