[
https://issues.apache.org/jira/browse/PDFBOX-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-2441.
----------------------------------------
Resolution: Fixed
{quote}
Sorry, I just see that the file I attached doesn't display properly in AR.
{quote}
No need to worry, I've got caught in the same trap. I've opened it in AR and
the first page looks fine. There isn't any error not until I scroll down.
Saying that, thanks for the sample pdf.
However the xref stream issue is solved. The remaining issue is something which
can't be fixed by any more or less intelligent algorithm. We have to skip such
broken parts in the future but that is another story, so that I'm setting this
issue to resolved.
> 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)
