Thanks for the code sample. I am able to replicate this problem, but on PDF 1.5+ files with cross reference streams only.
PDF::API2 is attempting to do an incremental-update; i.e. doing a byte-copy of the entire file, then writing just an update section.
One issue I can see is in the trailer. PDF::API writes:
xref
0 1
0000000000 65535 f
trailer
<< /Type /XRef /DecodeParms << /Columns 4 /Predictor 12 >> /Filter /Fl
+ateDecode /ID [ <0804b5bbf3a55e75ca368be05a5dbdf1> <49e68ac26e773d479
+329dad137f869c3> ] /Index [ 214 37 ] /Info 213 0 R /Length 86 /Prev 1
+16 /Root 215 0 R /Size 250 /W [ 1 2 1 ] >>
startxref
106778
%%EOF
But the format should be more like:
xref
0 1
0000000000 65535 f
trailer
<< /ID [ <0804b5bbf3a55e75ca368be05a5dbdf1> <49e68ac26e773d479329dad13
+7f869c3> ] /Info 213 0 R /Prev 116 /Root 215 0 R /Size 250
>>
startxref
106780
%%EOF
It's leaving some irrelevant 1.5 entries in the file trailer (/Type, /Columns, /Predictor, /Filter, /Index, /Length /W ...) when writing a 1.4 format trailer. Could be other issues.
Needs a ticket. I'll raise one when I get some clicks.
In the short term you can try converting the PDF files to 1.4 and see if that helps.
Update: The Perl 6 PDF module also has similar issues (I'm the author). I've raised a ticket there first.
Update2: - hopefully fixed in Perl 6 - There is already an open ticket (with a proposed solution) in PDF::API2 that I missed earlier. |