Hi all, thanks Hib for your comment. I did notice this fact while preparing the patch and modfied it to just skip whitespace. I shortly tested it before sending the patch to the list and it worked for both cases.
Thanks again. Am Freitag, 10. Juni 2011, 18:24:59 schrieb Hib Eris: > 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 -- regards Axel _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
