You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2014/10/22 19:11:34 UTC

[jira] [Commented] (PDFBOX-2441) Improve XRef self healing mechanism when more than one xref table

    [ https://issues.apache.org/jira/browse/PDFBOX-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14180185#comment-14180185 ] 

ASF subversion and git services commented on PDFBOX-2441:
---------------------------------------------------------

Commit 1633653 from [~lehmi] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1633653 ]

PDFBOX-2441: added check/repair of xref stream offset, rearrange some code

> Improve XRef self healing mechanism when more than one xref table
> -----------------------------------------------------------------
>
>                 Key: PDFBOX-2441
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-2441
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Parsing
>    Affects Versions: 1.8.7, 1.8.8, 2.0.0
>            Reporter: Tilman Hausherr
>            Assignee: Andreas Lehmkühler
>             Fix For: 1.8.8, 2.0.0
>
>         Attachments: 260105.pdf
>
>
> This is a follow-up issue to PDFBOX-2250:
> {quote}
> the xref repair algorithm simply searches for the nearest offset, which may fail if more than one xref table is present
> ...
> Once we have a sample pdf which can't be parsed with the simple algorithm, we can open a new issue.
> {quote}
> And here's one:
> {code}
> Exception in thread "main" java.io.IOException: Error: Expected a long type at offset 1180, instead got '50/Filter/FlateDecode/DecodeParms'
>         at org.apache.pdfbox.pdfparser.BaseParser.readLong(BaseParser.java:1690)
> {code}
> That file does have more than one xref table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)