-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi Glen,
(Apologies in advance if the post seems a bit long; really don't mean to
bore you ;-) )
snip /
With an FLM-centric approach, what I'm seeing is
something like either of these two: (pseudocode)
a) Within
Hi Andreas:
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
[Glen:]
With an FLM-centric approach, what I'm seeing is
something like either of these two: (pseudocode)
a) Within PSLM:
FlowLayoutManager flm = new
FlowLayoutManager(simplePageMaster);
while (pv =
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
snip /
I was thinking of the FLM controlling layout for *all*
the FO descendants of the fo:flow. One and only one
FLM instance for the fo:flow of an fo:page-sequence.
OK, clear now and fully agreed on this.
It returns
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
Indeed not. The FlowLM should definitely keep track
of this, when
applicable --in my description: the FlowLM would
store the reference to its
last processed descendant before the page overflow,
and the PageSequenceLM,
upon finishing one
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
Hmm.. This does seem to be one of those situations
where the logic could be
placed anywhere. However, taking into account Luca's
remarks, I would be
inclined to see it as:
The PSLM creates the page-viewports, and passes
them on to
1.
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
--- Luca Furini [EMAIL PROTECTED] wrote:
My first impression is that I would find somewhat
strange that the *page* breaking is not in the
*Page*SequenceLM! :-)
Well, under our current philosophy, our LM's map
Glen Mazza wrote :
# Andreas L. Delmelle wrote:
1.) If FOP is processing a block on the middle of page
17 with a break-before value of even-page, FOP is
supposed to render this block at the top of page 18
instead.
I agree.
2.) If FOP is processing a block on the middle of page
*18* with
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
Would we need a 'check' on whether the previous page already
contains areas generated by elements of a given BlockSequence
(or: whether the first area on curPage is also the first area
generated by an
-Original Message-
From: Luca Furini [mailto:[EMAIL PROTECTED]
Hi,
snip /
I don't know if the methods could be moved to the FLM: besides the break
value, they depend on the current page number and this is known only by
the PageSequenceLM.
Yeah, it was just a thought... I assumed
--- Luca Furini [EMAIL PROTECTED] wrote:
Break conditions in page breaking are quite similar
to preserved linefeeds
in line breaking: they divide a fo:page-sequence in
smaller sequences,
Another way of thinking about it would be that the
array of page-viewport-areas returned by this FO is
It seems there is a bug affecting the creation of the right kind of page
for documents containing blocks with break-* = odd-page or even-page.
If break-before = odd-page *each* page with some content is odd; even
pages are all empty.
If break-before = even-page the content is placed only on even
Just so I understand how this is supposed to work,
will someone please confirm my assumptions below:
1.) If FOP is processing a block on the middle of page
17 with a break-before value of even-page, FOP is
supposed to render this block at the top of page 18
instead.
and
2.) If FOP is processing
Also, as food for thought, I wonder if the two methods
Luca has mentioned should eventually be in
FlowLayoutManager (FLM) instead. The break properties
appear relevant only for fo:flow descendants.
Glen
--- Glen Mazza [EMAIL PROTECTED] wrote:
Just so I understand how this is supposed to work,
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Hi Glen,
Also, as food for thought, I wonder if the two
methods
Luca has mentioned should eventually be in
FlowLayoutManager (FLM) instead. The break
14 matches
Mail list logo
