[
https://issues.apache.org/jira/browse/PDFBOX-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055664#comment-18055664
]
ASF subversion and git services commented on PDFBOX-6159:
---------------------------------------------------------
Commit b4ada760a683ad9f8e40c3db8da0f228c0af35f3 in pdfbox-jbig2's branch
refs/heads/master from Tilman Hausherr
[ https://gitbox.apache.org/repos/asf?p=pdfbox-jbig2.git;h=b4ada76 ]
PDFBOX-6159: check symInRefSize for overshoot; fix check start position; seek
to correct position after reading (if symInRefSize larger than actual size)
> symInRefSize not respected when doing Huffmann decoding
> -------------------------------------------------------
>
> Key: PDFBOX-6159
> URL: https://issues.apache.org/jira/browse/PDFBOX-6159
> Project: PDFBox
> Issue Type: Sub-task
> Components: JBIG2
> Affects Versions: 3.0.4 JBIG2
> Reporter: Tilman Hausherr
> Assignee: Tilman Hausherr
> Priority: Major
> Fix For: 3.0.5 JBIG2
>
> Attachments: bitmap-symbol-symhuffrefineone.pdf,
> bitmap-symbol-texthuffrefine.pdf, bitmap-symbol-texthuffrefineB15.pdf,
> bitmap-symbol-texthuffrefinecustom.pdf,
> bitmap-symbol-texthuffrefinecustomdims.pdf,
> bitmap-symbol-texthuffrefinecustompos.pdf,
> bitmap-symbol-texthuffrefinecustomposdims.pdf,
> bitmap-symbol-texthuffrefinecustomsize.pdf
>
>
> After not progressing with Huffmann related problems (and working on
> bitmap-symbol-symhuffrefine-textrefine.jbig2), I had a look at the code by
> Nico Weber
> https://github.com/SerenityOS/serenity/blob/master/Userland/Libraries/LibGfx/ImageFormats/JBIG2Loader.cpp#L1560
> he reads symInRefSize bytes into a buffer after reading the size. The oiginal
> levigo code just decodes and ignores the value, i.e. assumes that it will
> land at the correct position.
> Thus the start position in my recent change should be another one than the
> one I assumed (after debugging "good" results), but then many that worked now
> failed like this:
> Refinement bitmap bytes expected: 28, bytes read: 26
> So either all these reads are wrong (although look ok), or the amount of
> bytes reserved is slightly too high, which is harmless.
> Thus I'll change it so that it checks only for an "overshoot" and seeks to
> the correct position after read.
> And suddenly lots of files were rendered properly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
