Nasty layout bug: maint vs. HEAD

["Andreas L. Delmelle" <a_...@pandora.be>]

Tried the following type of FO-document:

- one page-sequence with a sort of TOC, a fo:table with basic-links to
detail-blocks
- multiple page-sequences, one for each detail-block

In the test document, the TOC is about five pages, containing links to +/-
300 detail-blocks. The detail-blocks all take up one page each (for the
moment).

In 0.20.5 this works very fine... In HEAD strangely the document is layed
out such that the first TOC page ends up after the last detail-block for
which it contains the link...

Does anybody have an idea where the origin of this weirdness might be
located? :)

Cheers,

Andreas

RE: Nasty layout bug: maint vs. HEAD

["Andreas L. Delmelle" <a_...@pandora.be>]

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:a_l.delmelle@pandora.be]
> > -----Original Message-----
> > From: Simon Pepping [mailto:spepping@leverkruid.nl]
> > 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

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Simon Pepping [mailto:spepping@leverkruid.nl]
> 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 bug: maint vs. HEAD - Some Follow-up...

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Andreas L. Delmelle [mailto:a_l.delmelle@pandora.be]
>
> When debugging the output using the AreaTree XML, the pages are in the
> proper sequence in there (only, outside of their page-sequences?*), so

Correction: they are all inside one and the same page-sequence -the final
one, preceded by a set of empty page-seqs. In that one last page-sequence,
all viewports of the pages are rendered in the correct order. (for those
interested: I'll post a sample fileset shortly -- FO / PDF 1.0 / PDF 0.20.5
/ AT 1.0 / AT 0.20.5 ... still have to get rid of some info which can be
considered confidential )

Hmm. So it's the _sequences_ that are rendered out of order, and the
PDFRenderer's output doesn't correspond to that of the AreaTree, or does it?
It seems that there is not so much wrong with the out-of-order rendering
mechanism (except maybe for page-sequences, but we'd have to correct another
error first to make sure of that).
I'd think it's caused by the way Layout/Area processes the unresolved links.
Trying to explain both PDF and AreaTree output, this seems to be indicating
that an unresolved link creates a target page-viewport *in the same*
page-sequence. When the actual target page-sequence gets rendered, the
contents of this viewport do seem to be correctly linked, but they remain in
the former page-sequence(*), so the occupied memory doesn't get released.
The origin of the OOM Error --which happens already with docs of +/- 18
pages (using tables, of course :) )

As I noticed, maintenance doesn't produce page-sequences in the AreaTree
output, just pages, so this would definitely make resolving the links more
straightforward (--as there is no such thing as an 'inter-page-sequence
internal link')

In 0.20.5, unresolved links seem to be ultimately handled at Page level.
This approach is copied into HEAD, but it should be handled at PageSequence
level over there, I think --either that or the sequences shouldn't end up in
the AreaTree.


Cheers,

Andreas

(*) it's beginning to look like nothing more than a nasty mix-up of source
and target object somewhere... could it be as simple as that? It just seems
like the target page-sequence is being passed the link instead of the actual
target of the link, while the source page-sequence gets to keep all the
contents and passes these to the target page-sequence when the latter asks
for it.

RE: Nasty bug: maint vs. HEAD - Some Follow-up...

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Simon Pepping [mailto:spepping@leverkruid.nl]
>
> 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.
>

When debugging the output using the AreaTree XML, the pages are in the
proper sequence in there (only, outside of their page-sequences?*), so
fo:page-number works as expected, correct values on the correct
pages --only, the sequence gets screwed up when rendered to PDF.

* I wonder if this is in some way related to the memory problems I ran into.
Since 0.20.5 doesn't produce page-sequences in the AreaTree XML, and
performs the PDF rendering without problems.

Cheers,

Andreas

Re: Nasty layout bug: maint vs. HEAD

[Simon Pepping <sp...@leverkruid.nl>]

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

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Andreas L. Delmelle [mailto:a_l.delmelle@pandora.be]
> > -----Original Message-----
> > From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> >
> >
> > 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

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>
> 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

Re: Nasty layout bug: maint vs. HEAD

["J.Pietschmann" <j3...@yahoo.de>]

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