BTW: I ran a further test on a more extended version of the document ( TOC
of 6 pages + 338 detail pages ) without the basic-links. 0.20.5 had no
problems, while HEAD threw an OOM Error (both running with a max heap of

IMHO this would indicate that somehow the page-sequences aren't released
anymore (?) I ran the same test with only two page-sequences: one for the
TOC, the other for all 338 detail-pages. Memory seems to get maxed out at
+/- the same point in the process.

> -----Original Message-----
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
> > -----Original Message-----
> > From: Simon Pepping [mailto:[EMAIL PROTECTED]
> > On Sun, Feb 01, 2004 at 03:06:24AM +0100, Andreas L. Delmelle wrote:
> >
> > I have seen this problem too. The PDF renderer is able to render out
> > of order, but from this bug it seems that the mechanism is
> > broken. Could it be that the page is inserted at the point when all
> > its forward references are resolved? At that point it is rendered, but
> > the PDF renderer should insert it at the proper position. That does
> > not seem to happen.
> >
> Yup, that's exactly what it seemed like to me: a miscommunication between
> layout and renderer. (Mainly because I added some primitive
> logging messages
> to the version in my sandbox, I could see it 'happening' after
> the relevant
> code in the LM was executed.)
> And indeed, the first page containing the links appears right
> after the last
> page for which it contains the link, so at the point where all its forward
> refs are resolved.
> Thanks for the pointer. I'll surely have a closer look at that.
> (If you have
> any more ideas on this, I'll be glad to read about them).
> Cheers,
> Andreas

Reply via email to