Hi Axel, Thank you for reporting this issue.
On Thu, Jun 9, 2011 at 6:53 PM, Axel Strübing <[email protected]> wrote: > Dear popplers > > there seems to be a problem in PDFDoc::writeTrailer. > > For incremental updating linearized pdffiles the result of getStartXRef() is > written as the "/Prev" entry in the trailer dictionary. > The value is determined from the offset after the first 'endobj' string in the > file. In my example this is not the offset of the expected 'xref' keyword. > > Unfortunately the parser/lexer in poppler is more tolerant than other ... > So I have other software that is rejecting the poppler saved files as invalid > :-( > > Could you check if the following change in PDFDoc.cc would do more harm than > good? It is only used in building the XRef instance. > ------------ change following lines ------------ > for (i = 0; i < n; i++) { > if (!strncmp("endobj", &buf[i], 6)) { > startXRefPos = i+6; > break; > } > } > ------------ to ------------------------------------ > for (i = 0; i < n; i++) { > if (!strncmp("xref", &buf[i], 4)) { > startXRefPos = i; > break; > } > } >From trying to remember why I wrote the code as it is now, I think the problem with your patch is that it only handles 'old style' xref tables, but fails on xref streams. See XRef.cc:435. Can you rewrite your patch to handle that? E.g. by searching for 'endobj' and than skipping over whitespace? Hib Eris _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
