RE: Nasty layout bug: maint vs. HEAD

2004-02-01 Thread Andreas L. Delmelle
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
128MB).

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
>
>
>
>



RE: Nasty layout bug: maint vs. HEAD

2004-02-01 Thread Andreas L. Delmelle
> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
> On Sun, Feb 01, 2004 at 03:06:24AM +0100, Andreas L. Delmelle wrote:
> > > -Original Message-
> >
> > To clear that up a bit further:
> >
> > If you run a document structured like this, but with many more
> > page-sequences, through HEAD, the whole document will be
> divided into chunks
> > of about 60 pages ( +/- the number of lines in the table-body
> of the TOC ),
> > and in between you will find the TOC pages themselves.
>
> 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



Re: Nasty layout bug: maint vs. HEAD

2004-02-01 Thread Simon Pepping
On Sun, Feb 01, 2004 at 03:06:24AM +0100, Andreas L. Delmelle wrote:
> > -Original Message-
> 
> To clear that up a bit further:
> 
> If you run a document structured like this, but with many more
> page-sequences, through HEAD, the whole document will be divided into chunks
> of about 60 pages ( +/- the number of lines in the table-body of the TOC ),
> and in between you will find the TOC pages themselves.

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.

Regards,
Simon Pepping

-- 
Simon Pepping
home page: http://www.leverkruid.nl



RE: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
> > -Original Message-
> > From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> >
> >
> > I don't understand the problem. Could you trim it down to two
> > detail blocks,
> > and post the FO (assuming the trimmed down FO still has the problem)?
> >
>
> Sure. In attach.
>

To clear that up a bit further:

If you run a document structured like this, but with many more
page-sequences, through HEAD, the whole document will be divided into chunks
of about 60 pages ( +/- the number of lines in the table-body of the TOC ),
and in between you will find the TOC pages themselves.

I must admit: it *does* have a certain logic to it I can appreciate, but it
would somehow seem far from compliant :)

Cheers,

Andreas



RE: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread Andreas L. Delmelle
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
>
> Andreas L. Delmelle wrote:
> > In 0.20.5 this works very fine... In HEAD strangely the
> document is layed
>
>  ^
>
>  laid :-)
>

Ahem... Sorry 'bout that.

> > out such that the first TOC page ends up after the last detail-block for
> > which it contains the link...
>
> I don't understand the problem. Could you trim it down to two
> detail blocks,
> and post the FO (assuming the trimmed down FO still has the problem)?
>

Sure. In attach.

Cheers,

Andreas


testrekov.fo
Description: Binary data


Re: Nasty layout bug: maint vs. HEAD

2004-01-31 Thread J.Pietschmann
Andreas L. Delmelle wrote:
In 0.20.5 this works very fine... In HEAD strangely the document is layed
  ^
  laid :-)
out such that the first TOC page ends up after the last detail-block for
which it contains the link...
I don't understand the problem. Could you trim it down to two detail blocks,
and post the FO (assuming the trimmed down FO still has the problem)?
J.Pietschmann