Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Commit [7ce0fa] Maximize Restore History

kernel: handle hybrid-xref files correctly in XRefWriter

Fixes bt#338

PDF 1.5 and above versions of specification support so called hybrid files
which contain both old-style xref table and xref stream. Such a document
then looks as follows:

[@OFFSET2]
xref
[Standard xref entries. Hidden objects are marked as free with max gen
number]

trailer
<<
/Root [...]
>>

[@OFFEST3]
1 0 obj
<<
/Length [...]
>>
stream
[object stream data]
endstream

[@OFFSET1]
xref
0 0
trailer
<<
/Prev OFFSET2
/XRefStm OFFSET3
>>

startxref
OFFSET1
%EOF

This means that this kind of file looks like a 2 revisions document. This
wouldn't be a big problem but we have a different problem if we consider
this to be 2 revisions document. XRefWriter::getRevision size calculates
revision size which is done as revStart-endPrev (where endPrev is the end
of the previous revision), but we are not able to calculate end of the
previous revision because xref (at OFFSET2) is not followed by startxref
keyword as expected. Application then ends with assertion failure
revStar>endPrev.

Of course we could fix the XRefWriter::getRevisionEnd but the point is that
we shouldn't consider this layout multi-version in the first place. The
"proper" fix is not considering additional xref for hybrid files at all.
This is done in XRefWriter::collectRevisions by checking XRefStm entry in
the trailer.

If a hybrid document is multiversion then the referenced trailer (OFFSET2)
should contain /Prev entry IMO. The PDF specification is not clear in this
regard.

Michal Hocko Michal Hocko 2009-10-22

changed src/kernel/xrefwriter.cc
src/kernel/xrefwriter.cc Diff Switch to side-by-side view
Loading...