You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andreas Delmelle <an...@telenet.be> on 2008/09/01 23:20:29 UTC
Re: I need fo:retrieve-table-marker example or how to implement continued label in FOP-95?
On Sep 1, 2008, at 23:02, Andreas Delmelle wrote:
(Moving this to fop-dev@)
> On Sep 1, 2008, at 22:42, Jean-François El Fouly wrote:
>> Hhmm... I've been quickly through the code and my first impression
>> is that it IS implemented.
>
> Not really, I'm afraid. I have prepared the implementation a while
> ago. That much is true. FOP simply does nothing with a retrieve-
> table-marker node, but the node is created and the properties
> parsed. Only in layoutmgr.LayoutManagerMapping, you will notice
> that the RetrieveTableMarker generates no LayoutManager yet.
>
>> I've set up a simple test case and, going through the stack trace,
>> I guess it could be a simple bug fix, something like a bad or
>> insufficient test in TablePart.java
>
> Oh, rest assured, it's going to take a bit more thought and
> effort... ;-)
To spare some time looking, I see one issue that may turn out to be
quite a challenge.
One significant benefit is that it operates on the same fo:markers,
so little work there, and it may even give you some ideas on how to
solve it for the table-case, however...
If you follow what happens during regular marker-retrieval, you'll
notice that the resolution depends on the markers having been added
to the page-viewport.
This happens in the addAreas() phase. Later, when the page is
finalized, the static-content is added, and at that point the markers
are readily available.
For a table-header (or -footer), there will be an additional
difficulty, because at the point where we generate the base element
list, the markers will not have been processed, so we cannot really
depend on that same mechanism... Strictly speaking, we might also end
up with borderline cases, where the table-header's height varies from
page to page, depending on the content retrieved in the marker. Not
sure, but the table-code may need some work to cater for this.
Just so you know what you're getting yourself into. ;-)
Then again, we're here for you, if you get stuck.
Cheers
Andreas
Re: I need fo:retrieve-table-marker example or how to implement continued
label in FOP-95?
Posted by Vincent Hennebert <vh...@gmail.com>.
For the sake of completeness, see this message and the following ones in
the same thread:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200805.mbox/<48...@anyware-tech.com>
Some non-trivial changes are indeed necessary in the table layout
code... and might be further invalidated by the new page layout
approach.
Vincent
Jeremias Maerki wrote:
> On 01.09.2008 23:20:29 Andreas Delmelle wrote:
>> On Sep 1, 2008, at 23:02, Andreas Delmelle wrote:
>>
>> (Moving this to fop-dev@)
>>
>>> On Sep 1, 2008, at 22:42, Jean-François El Fouly wrote:
>>>> Hhmm... I've been quickly through the code and my first impression
>>>> is that it IS implemented.
>>> Not really, I'm afraid. I have prepared the implementation a while
>>> ago. That much is true. FOP simply does nothing with a retrieve-
>>> table-marker node, but the node is created and the properties
>>> parsed. Only in layoutmgr.LayoutManagerMapping, you will notice
>>> that the RetrieveTableMarker generates no LayoutManager yet.
>>>
>>>> I've set up a simple test case and, going through the stack trace,
>>>> I guess it could be a simple bug fix, something like a bad or
>>>> insufficient test in TablePart.java
>>> Oh, rest assured, it's going to take a bit more thought and
>>> effort... ;-)
>> To spare some time looking, I see one issue that may turn out to be
>> quite a challenge.
>> One significant benefit is that it operates on the same fo:markers,
>> so little work there, and it may even give you some ideas on how to
>> solve it for the table-case, however...
>>
>> If you follow what happens during regular marker-retrieval, you'll
>> notice that the resolution depends on the markers having been added
>> to the page-viewport.
>> This happens in the addAreas() phase. Later, when the page is
>> finalized, the static-content is added, and at that point the markers
>> are readily available.
>>
>> For a table-header (or -footer), there will be an additional
>> difficulty, because at the point where we generate the base element
>> list, the markers will not have been processed, so we cannot really
>> depend on that same mechanism... Strictly speaking, we might also end
>> up with borderline cases, where the table-header's height varies from
>> page to page, depending on the content retrieved in the marker. Not
>> sure, but the table-code may need some work to cater for this.
>
> Absolutely. At the moment the element list for headers and footers is
> calculated once (in TableContentLayoutManager) and then used for every
> break possibility (see TableHFPenaltyPosition). When
> retrieve-table-markers are used you basically have to recalculate the
> header and footer element lists for each break position in case the
> markers change.
>
> That's quite a bit of processing effort that is even mostly done in vain
> since most break positions won't even be used. But since we're still on
> a total-fit approach, that is necessary. That should improve when
> Vincent is finished with his revamping of the page breaking process.
>
>> Just so you know what you're getting yourself into. ;-)
>>
>> Then again, we're here for you, if you get stuck.
>>
>> Cheers
>>
>> Andreas
>>
>
>
>
>
> Jeremias Maerki
Re: I need fo:retrieve-table-marker example or how to implement continued label in FOP-95?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 01.09.2008 23:20:29 Andreas Delmelle wrote:
> On Sep 1, 2008, at 23:02, Andreas Delmelle wrote:
>
> (Moving this to fop-dev@)
>
> > On Sep 1, 2008, at 22:42, Jean-François El Fouly wrote:
> >> Hhmm... I've been quickly through the code and my first impression
> >> is that it IS implemented.
> >
> > Not really, I'm afraid. I have prepared the implementation a while
> > ago. That much is true. FOP simply does nothing with a retrieve-
> > table-marker node, but the node is created and the properties
> > parsed. Only in layoutmgr.LayoutManagerMapping, you will notice
> > that the RetrieveTableMarker generates no LayoutManager yet.
> >
> >> I've set up a simple test case and, going through the stack trace,
> >> I guess it could be a simple bug fix, something like a bad or
> >> insufficient test in TablePart.java
> >
> > Oh, rest assured, it's going to take a bit more thought and
> > effort... ;-)
>
> To spare some time looking, I see one issue that may turn out to be
> quite a challenge.
> One significant benefit is that it operates on the same fo:markers,
> so little work there, and it may even give you some ideas on how to
> solve it for the table-case, however...
>
> If you follow what happens during regular marker-retrieval, you'll
> notice that the resolution depends on the markers having been added
> to the page-viewport.
> This happens in the addAreas() phase. Later, when the page is
> finalized, the static-content is added, and at that point the markers
> are readily available.
>
> For a table-header (or -footer), there will be an additional
> difficulty, because at the point where we generate the base element
> list, the markers will not have been processed, so we cannot really
> depend on that same mechanism... Strictly speaking, we might also end
> up with borderline cases, where the table-header's height varies from
> page to page, depending on the content retrieved in the marker. Not
> sure, but the table-code may need some work to cater for this.
Absolutely. At the moment the element list for headers and footers is
calculated once (in TableContentLayoutManager) and then used for every
break possibility (see TableHFPenaltyPosition). When
retrieve-table-markers are used you basically have to recalculate the
header and footer element lists for each break position in case the
markers change.
That's quite a bit of processing effort that is even mostly done in vain
since most break positions won't even be used. But since we're still on
a total-fit approach, that is necessary. That should improve when
Vincent is finished with his revamping of the page breaking process.
> Just so you know what you're getting yourself into. ;-)
>
> Then again, we're here for you, if you get stuck.
>
> Cheers
>
> Andreas
>
Jeremias Maerki