| Summary: | Doesn't render correctly a JBIG2 based PDF | ||
|---|---|---|---|
| Product: | poppler | Reporter: | Albert Astals Cid <aacid> |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Fixes DecryptStream::getPos() | ||
|
Description
Albert Astals Cid
2009-01-23 14:13:24 UTC
Created attachment 26981 [details] [review] Fixes DecryptStream::getPos() This patch appears to fix the bug. The problem is that JBIG2Stream uses the Stream::getPos() of wrapped streams to determine segment length, specifically whether too many or too few characters have been read. A LOT of streams don't provide sane values and this trips up JBIG2Stream. (Notably ones that subclass FilterStream. FilterStream provides a default implementation of getPos() which is often wrong. It only works if the Filter does not blow up or shrink the data, i.e. there is one and only one call to str->readChar() for every call to readChar().) The culprit in this case was DecryptStream. Commited, keep up the good work :-) |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.