It took a bit of work to get to the bottom of this one, but I think I have it. In fact the problem doesn’t really have anything to do at all with the lack of a trailer: Pdftk can handle this case okay, though the way it does it did cause a spurious exception here, which put me on the wrong track for a while.
The actual bug is in the method PRTokeniser#nextValidToken. This method has the feature that it treats an indirect object reference (such as 24 0 R) as a single token. Therefore when it sees a number, it has to look ahead to see if the number is actually the start of an indirect object reference. If, however, the object stream ends during this lookahead then it would wrongly fail. So it will go wrong whenever the last object in an object stream is a number. It is perhaps surprising that this causes so apparently few problems! The attached patch (against Pdftk 1.45) corrects this issue, and appears to fix the problem with Yaroslav’s example file. Robin
963ed82.patch
Description: Binary data
