Hi,
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.
David Benjamin
commit f583ac754b5e77a6416709c21c79c675a691b4ad
Author: David Benjamin <[email protected]>
Date: Sun Jun 7 20:41:38 2009 -0400
Reimplement getPos() in JBIG2Stream
FilterStream calls str->getPos() which is bypassed in JBIG2Stream in favor of
curStr in JBIG2Stream::reset(). This broke extraneous-byte-detection logic and
misparsed PDFs on http://www.adobe.com/products/acrcapture/agentpack/index.html
diff --git a/poppler/JBIG2Stream.h b/poppler/JBIG2Stream.h
index ca1fee7..69ac302 100644
--- a/poppler/JBIG2Stream.h
+++ b/poppler/JBIG2Stream.h
@@ -36,6 +36,7 @@ public:
virtual StreamKind getKind() { return strJBIG2; }
virtual void reset();
virtual void close();
+ virtual int getPos() { return curStr->getPos(); }
virtual int getChar();
virtual int lookChar();
virtual GooString *getPSFilter(int psLevel, char *indent);
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler
