feat: allowing offset xref table with pdf parser #277
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
attempting to solve #274.
in the presented case there's an offset xref, in that it is positioned 8 bytes later than where the declared position is. This is also true for the rest of the positions within the xref.
this solution tries to parse later, up to 1024 bytes, for a next position that might be an xref start, per what is considered an xref (xref symbol or integer). the offset is stored as additional offset (to potential initial header offset) so that the rest of the read positions can be translated to the correct ones...again assuming that offset is constant.