[poppler] another problem with saving linearized files

[Axel Strübing]

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 <axel.struebing at freenet.de> 
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