RE: Problems with break conditions and empty pages
-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 PSLM:
FlowLayoutManager flm = new
FlowLayoutManager(simplePageMaster);
while (pv = flm.getNextPageViewport() != null) {
addStaticContent(pv); // done for *every* PV
areaTreeModel.renderPage(pv);
}
I don't quite get this...
With the FLM controlling layout for a subset of the descendants of an
fo:flow, I didn't exactly mean there should be a one-to-one relation between
FLMs and those subsets (or even between the FLMs and the
pages/page-masters).
More like: the FLM holds a reference to the entire set of descendants, which
it may or may not be able to layout all on one page --depending on the
properties of the page-master that is used to create the first page-viewport
that the PSLM provides it with.
If the content fits in one page --sufficiently low bpd or indefinite
page-height-- no additional pages are requested from the PSLM.
If it doesn't fit in one page --bpd too high or forced page-breaks-- the FLM
signals to the PSLM if and when it needs a new page, so that the PSLM can:
a. finish up the current one -- instruct SCLMs to layout their content to
the assigned region-viewports.
(and if there's any content left in the flow)
b. create a main viewport for the next page(s)
c. instruct FLM to resume layout where it left off, handing it the freshly
created viewport as a blank canvas
(step a. is always performed, b. and c. depend on the nature of the message
the PSLM receives from the FLM --break forced? empty page needed?
descendants left?)
The real 'page-breaking' is done by the PSLM, but not completely
out-of-the-blue. It just creates the pages on-demand, using page-masters
defined higher up, but *as needed* by the FLM. So, in a sense, the
'page-breaking' can also be considered to take place at levels far deeper
than the FLM --fo:blocks with forced page-breaks.
To revisit the implementation of spans:
My idea would be to insert a class between AbstractLM and
FlowLM(/StaticContentLM?) --a subclass of the first, superclass of the
latter-- that offers the interface for handling multi-column/span layout.
The FlowLM (and StaticContentLM?) would take care of forced column-breaks
within the page the PageSequenceLM has created for them (or: whether a
region to which the flow/static content is assigned has multiple columns, is
ultimately determined in the page-master...).
The inter-class' functionality would contain the default logic for handling
one-column layout, and more...
WRT implementing footnotes and floats, I see a few possibilities:
1) The FLM first performs layout, ignoring the footnotes/floats.
(not really 'ignoring', but storing them in a map at page-level)
When the page is full, redo the layout for this page, _starting_
with footnotes/before-floats, then moving on to the normal areas.
2) The FLM performs layout for the normal areas, _until_ a
footnote/float is encountered, and restarts layout for this page,
starting with the footnote/float (etc.)
3) The FLM performs layout for the normal areas, and upon
encountering footnotes/floats, immediately performs layout for
them, and subtracts the resulting bpd from the total bpd available
for the remaining normal areas.
Depending on the number of footnotes/floats for a page, option 2) could mean
a significant overhead (since layout must be paused/restarted multiple
times). Option 1) could also become very tricky...
Option 3) seems the better bet so far. It results in all info necessary to
process the page being available after one pass --IIC, at most some
re-arranging of the created areas is needed, if we can't do it on-the-fly,
that is (i.e. instead of merely 'subtracting' the bpd for a before-float,
also immediately adjust the top co-ordinates for the normal areas already
generated for this page)
If anyone sees another alternative for this, I'm all ears...
snip /
Also: PSLM needs to provide FLM the following:
1.) getBeforeFloatSeparator();
2.) getFootnoteSeparator();
How these two are provided I'm not sure at the moment:
have PSLM render these two by calling a SCLM, have
FLM render them by calling a SCLM, etc. -- I don't
know.
If the mentioned separators can be considered part of the static content,
they could be handled by the SCLM --since the SCLM would perform its tasks
*after* the FLM has done its job for the page, it has all info WRT the
presence of floats/footnotes for the given page at its disposal.
If, OTOH, the separators do not/cannot have an effect on the placement of
the static content --which I would intuitively presume to be the case, but
I'll have to check the Rec for certainty--, then it would seem more logical
to have the FLM process the separators (if and when processing the
before-floats/footnotes
RE: Problems with break conditions and empty pages
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 = flm.getNextPageViewport() != null) {
addStaticContent(pv); // done for *every* PV
areaTreeModel.renderPage(pv);
}
I don't quite get this...
With the FLM controlling layout for a subset of the
descendants of an
fo:flow,
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.
It returns PageViewport instances to PSLM as it does
its processing.
I didn't exactly mean there should be a
one-to-one relation between
FLMs and those subsets (or even between the FLMs and
the
pages/page-masters).
I'm unsure what you mean by subsets--while forced
page-breaks may cause the Knuth algorithms to need to
group up the PageViewports generated by the FLM into
subsets for each subset to get optimized, that is IMO
an FLM-specific implementation detail that PSLM
ideally shouldn't need to be concerned about.
More like: the FLM holds a reference to the entire
set of descendants, which
it may or may not be able to layout all on one page
--depending on the
properties of the page-master that is used to create
the first page-viewport
that the PSLM provides it with.
IMO the FLM is a PageViewport-generating (and
-returning) machine--with the number of pages it needs
dependent upon the FLM's implementation, page breaking
strategies, etc. My FLM may return 54 PV's to the
PSLM for a given page-sequence -- your might return 50
for example.
If the content fits in one page --sufficiently low
bpd or indefinite
page-height-- no additional pages are requested from
the PSLM.
This is all FLM needs to do to create a fully
initialized PV: PV pv = new PV(spm); Why bother
having PSLM declare and feed it to FLM each time?
Just another unneeded moving part. FLM can fill up
the BodyRegion and send it back to PSLM for it to do
the StaticContent/SideRegions.
If it doesn't fit in one page --bpd too high or
forced page-breaks-- the FLM
signals to the PSLM if and when it needs a new page,
so that the PSLM can:
a. finish up the current one -- instruct SCLMs to
layout their content to
the assigned region-viewports.
(and if there's any content left in the flow)
b. create a main viewport for the next page(s)
Actually, PSLM doesn't do that anymore. PV creates
itself interally, including its subareas. That's what
allows us to discuss creating PV's in either FLM or
PSLM. PSLM has way too much logic to handle than to
get into the irrelevant minutae of creating a PV.
(You may be forgetting also that PSLM will also need
to handle Flow Maps in the future.)
c. instruct FLM to resume layout where it left off,
handing it the freshly
created viewport as a blank canvas
This is what is driving me crazy: I said three weeks
ago, let's call FLM BodyRegionLM instead, because it
is just doing page-by-page layout, with everything
being controlled by PSLM and you said no, no, no--it
processes the entire Flow--so call it FLM.
Now, you disagree in having FLM process the entire
flow, you want FLM to be page-by-page, i.e., a
BodyRegionLM but not called that. I can accept either
implemention--although I do prefer having the FLM
now--but its name should be consistent with what it
does.
It just creates the pages
on-demand, using page-masters
defined higher up, but *as needed* by the FLM.
Be careful, never say pages unless you are talking
about the physical medium. Say
PageViewports/page-viewport-areas instead.
Also, page-masters are not defined higher-up, they
are defined *separately* (in fo:layout-master-set) and
should be available for any LM that references their
values.
So,
in a sense, the
'page-breaking' can also be considered to take place
at levels far deeper
than the FLM --fo:blocks with forced page-breaks.
That granularity I'm not at yet to be able to
comment--I currently just prefer it to be outside of
PSLM in FLM.
To revisit the implementation of spans:
snip/
This I also don't have an opinion on right now, other
than to say that since the since fo:s-c can
unfortunately be redirected to the fo:region-body, it
will eventually need to handle columns as well. Your
idea may very well take care of this issue--I haven't
an alternative ATM.
WRT implementing footnotes and floats, I see a few
possibilities:
1) The FLM first performs layout, ignoring the
footnotes/floats.
I don't think it can ignore it, at the very least it
will need the BPD that the separators take up in order
to do its space calculations when footnotes/floats
occur.
I suspect the PSLM will pre-create each SCLM instance
for footnote/float separators. (i.e., we don't create
and initialize these objects for every page), so the
FLM
RE: Problems with break conditions and empty pages
-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 PageViewport instances to PSLM as it does its processing. And here the viewpoints differ, it seems... You would have the FLM create the actual PageViewports, on the basis that _it_ needs them anyway, and the PSLM would, strictly speaking, only need them when they are 'filled' --as a return value. The described approach is that the PSLM creates these viewports (or 'catches' them when they are created), passes them to the FLM and SCLM, and the latter merely 'signal' when their work is done with that viewport and whether they need another one. I didn't exactly mean there should be a one-to-one relation between FLMs and those subsets (or even between the FLMs and the pages/page-masters). I'm unsure what you mean by subsets... Yaa, sorry about that. It's just to give a name to a set of descendants of an fo:flow that, when fully rendered, would more or less correspond to one page in the output. It's merely of conceptual use, doesn't correspond to a real variable somewhere. --while forced page-breaks may cause the Knuth algorithms to need to group up the PageViewports generated by the FLM into subsets for each subset to get optimized, that is IMO an FLM-specific implementation detail that PSLM ideally shouldn't need to be concerned about. 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 total page-vp, would simply instruct the FlowLM to 'continue, wherever it left off'. More like: the FLM holds a reference to the entire set of descendants, which it may or may not be able to layout all on one page --depending on the properties of the page-master that is used to create the first page-viewport that the PSLM provides it with. IMO the FLM is a PageViewport-generating (and -returning) machine No, the 'M' is for 'Manager'... From the POV of the FlowLM, the constraints on the total layout dimension of the areas geneated by its descendants is not something it *needs* to have any control over itself --let alone: create at will :-/ --with the number of pages it needs dependent upon the FLM's implementation, page breaking strategies, etc. My FLM may return 54 PV's to the PSLM for a given page-sequence -- your might return 50 for example. Well, your FLM would generate viewports filled with areas, where mine would layout areas *to* one or multiple viewports... Which one makes more sense? I really can't say right now. If the content fits in one page --sufficiently low bpd or indefinite page-height-- no additional pages are requested from the PSLM. This is all FLM needs to do to create a fully initialized PV: PV pv = new PV(spm); Why bother having PSLM declare and feed it to FLM each time? Because it _feels_ right :-) No, seriously: because the PageSequenceLM corresponds to the fo:page-sequence, and the fo:page-sequence... Well, the Rec states it best: 6.4.1.4 Flows and Flow Mapping ... The processing of the fo:flow flow is what determines how many pages are generated to hold the fo:page-sequence. The fo:page-sequence-master is used as the generator of the sequence of page-masters into which the flow children content is distributed. ...and the fo:page-sequence-master is linked in too-many-ways-to-mention to the fo:page-sequence directly (not, or only indirectly to, the fo:flow). Just another unneeded moving part. FLM can fill up the BodyRegion and send it back to PSLM for it to do the StaticContent/SideRegions. Or it can fill up the readily created BodyRegion, and signal the PSLM that the layout for the static content may begin... Hmm, maybe the real fun of it is: if you would really like to wait until the end of the PageSequence to layout the static content for all pages...? Well, anyway, that would work equally well in both approaches. snip / Actually, PSLM doesn't do that anymore. PV creates itself interally, including its subareas. That's what allows us to discuss creating PV's in either FLM or PSLM. PSLM has way too much logic to handle than to get into the irrelevant minutae of creating a PV. (You may be forgetting also that PSLM will also need to handle Flow Maps in the future.) So, there will be a possible N flows for one page-sequence...? All the more reason, it seems, to centralize the page-generation at the 'one' end of that branch... c. instruct FLM to resume layout where it left off, handing it the freshly created viewport as a blank canvas This is what is driving me crazy: Good, me too! ;-P Errm, no wait a minute... I said three weeks ago,
RE: Problems with break conditions and empty pages
--- 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 total page-vp, would simply instruct the FlowLM to 'continue, wherever it left off'. OK. Not a problem here. No, the 'M' is for 'Manager'... From the POV of the FlowLM, the constraints on the total layout dimension of the areas geneated by its descendants is not something it *needs* to have any control over itself --let alone: create at will :-/ Well I think different FLM's would make different judgment calls in terms of page breaking mechanisms and/or column balancing, at least. ...and the fo:page-sequence-master is linked in too-many-ways-to-mention to the fo:page-sequence directly (not, or only indirectly to, the fo:flow). I don't think this matters all that much. Just another unneeded moving part. FLM can fill up the BodyRegion and send it back to PSLM for it to do the StaticContent/SideRegions. Or it can fill up the readily created BodyRegion, and signal the PSLM that the layout for the static content may begin... Hmm, maybe the real fun of it is: if you would really like to wait until the end of the PageSequence to layout the static content for all pages...? No...do it after each page is done...because that is how it is sent to the AreaTreeModel for rendering. However, and this is where the main issue will be, the FLM may need to juggle three or four PV's at a time while it is determining optimal Knuth page breaks, etc. Once all that is determined, *then* send them back one-by-one to PSLM. However, I will stay out of this issue for the moment and await comments from Luca and/or others on the team. This is outside my scope of knowledge. So, there will be a possible N flows for one page-sequence...? All the more reason, it seems, to centralize the page-generation at the 'one' end of that branch... I think they will be used more commonly for fo:static-content objects (print the same information in both the region-before and region-after, etc.) Yes and no :-) It performs layout for the entire flow, on a page-by-page basis, in close co-operation with the PageSequenceLM --and the StaticContentLM, if necessary for static-content float/footnote separators. Start-pause-resume-pause-resume... It flows its content, bit by bit --reporting to PSLM, and handing over control every page or so. OK--sounds good. Thanks, Glen
RE: Problems with break conditions and empty pages
--- 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. the FLM --which controls layout of a subset of
the areas
generated by descendants of the fo:flow
(ultimately also floats/footnotes)
2. the SCLMs --which control layout of the areas
generated
by the descendants of the fo:static-contents
(+ possible retrieved markers from the subset
processed
by the FLM)
I like this.
In this respect, the page-breaking logic is already
at its most appropriate
place.
The FLM needs only a part of the total page-vp, so
it makes sense to handle
the creation/initialization of the viewport one
level up.
Actually, creating/initializing a PageViewport is
not a big deal anymore--all PSLM does these days is:
PageViewport pv = new PageViewport(simplePageMaster);
That's it. The details of setting up
region-reference-areas, page-reference-areas, etc., is
all automatically done in PageViewport and related
Area classes. So this one-line initialization can be
done by FLM or PSLM wherever convenient.
If we go this route--and it's primarily dependent on
whether Luca is comfortable with it and sees
sufficient benefits to it--the total number of
pageViewports needed for a page-sequence would be a
function of the page-breaking and layout strategy of
the *FLM*, not the PSLM. For example, FLM may not
immediately be able to support multiple columns and
column balancing--output is single-column only. Once
we have columns column-balancing implemented in FLM,
probably a different number of PV's would be needed
for a given page-sequence. Or, different Knuth
implementations in FLM result in a different PV count.
Also, (say) Finn, via our pluggable layout manager
mechanism, decides to implement a different FLM, again
changing the number of PV's needed, etc., etc. PSLM
can remain the same regardless of FLM implementation.
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 = flm.getNextPageViewport() != null) {
addStaticContent(pv); // done for *every* PV
areaTreeModel.renderPage(pv);
}
(getNextPageViewport() returns one PV object with its
flow information populated.)
b.) Or, have a push mechanism in PSLM:
FlowLayoutManager flm = new flm(simplePageMaster);
flm.doLayout();
public void pageViewportFinished(pv) { // called by
FLM
addStaticContent(pv); // done for *every* PV
areaTreeModel.renderPage(pv);
}
Also: PSLM needs to provide FLM the following:
1.) getBeforeFloatSeparator();
2.) getFootnoteSeparator();
How these two are provided I'm not sure at the moment:
have PSLM render these two by calling a SCLM, have
FLM render them by calling a SCLM, etc. -- I don't
know.
Thanks,
Glen
RE: Problems with break conditions and empty pages
-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 to the formatting object (here, the page sequence), not the areas they generate. I was reminded a bit on that a few weeks ago by Andreas and Simon. You may recall, I recommended at the time that we have BodyRegionLM and a SideRegionLM instead of a FLM and a StaticContentLM. Under this scenario, PSLM controls complete page-by-page layout, and delegates to the BRLM and SRLM to do the body region or side areas. But if we have an FLM instead, my thinking is that it should perhaps process the entire fo:flow--including the creation of multiple page-viewport-areas in order to consume that flow. 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. the FLM --which controls layout of a subset of the areas generated by descendants of the fo:flow (ultimately also floats/footnotes) 2. the SCLMs --which control layout of the areas generated by the descendants of the fo:static-contents (+ possible retrieved markers from the subset processed by the FLM) In this respect, the page-breaking logic is already at its most appropriate place. The FLM needs only a part of the total page-vp, so it makes sense to handle the creation/initialization of the viewport one level up. A more serious comment is that some formatting objects (footnotes and before floats) generates page-level-out-of-line-areas, whose placement, according to the recommendation (4.2.5), is controlled by the fo:page-sequence ancestor; snip / As for location controlled by the fo:page-sequence ancestor, that could simply mean that the fo:page-sequence defines the page margins and the side region dimensions. The footnote is just above the region-after, and before-floats are just below the region-before, hence the fo:page-sequence determines its location. This wouldn't necessarily mean that the actual layout of these objects needs to be done by the PSLM. Indeed not. After all, both before-floats and footnotes *are* descendants of an fo:flow (assigned to the region-body, IIC --see constraints for fo:float w/ float=before and footnotes(*)) so, if the PSLM must handle footnotes and before floats (influencing the available bpd for the normal areas) it must handle the whole page breaking process. No, the FLM must handle the footnotes and before-floats, but the PSLM must handle the page-breaking... Since the out-of-line objects are constrained to the flow (region-body), it is not necessary to handle their processing higher up. Well, the available maximum bpd can be accessed from the area.BodyRegion child of the PageViewport--this value is calculated automatically upon initialization of a PageViewport. As you can see from section 6.10.1.3[1], these two areas consume space from the main-reference-area. So it appears that all that would be necessary is for the FLM to create a PageViewport, and if a flow has a before-float or footnote, reduce that bpd for the regular normal-reference-areas. (Also, to add the footnote/before-float separators in.) The _creation_ of the page-viewports should be done by the PSLM, while _dividing_ the assigned region-viewport's bpd over floats, footnotes and/or block content is up to the FLM. Cheers, Andreas (*) http://www.w3.org/TR/xsl/slice6.html#fo_float http://www.w3.org/TR/xsl/slice6.html#fo_footnote
Re: Problems with break conditions and empty pages
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 a break-before value of even-page, FOP is supposed to render it at the top of page 20 instead. I agree. 3.) The above processing is done only once for the fo:block with this property. I.e., assuming no child of fo:block has this property as well, if the block takes up multiple pages it will use pages 18-19-20-21-22..., for (1) above, and *not* 18-20-22-24... I agree. I think this is the right behaviour even if the block creates just a few lines, but the following blocks have no break conditions. Break conditions in page breaking are quite similar to preserved linefeeds in line breaking: they divide a fo:page-sequence in smaller sequences, just as preserved linefeeds make the block create more than one paragraph. fo:flow ... fo:blockBlock 1 ./fo:block fo:block break-before=odd-pageBlock 2 ./fo:block fo:blockBlock 3 ./fo:block fo:blockBlock 4 ./fo:block fo:block break-before=even-pageBlock 5 ./fo:block /fo:flow The break properties divide the content in three different sub-page-sequences: - the first one must start on any page and contains block 1 - the second one must start on an odd page and contains block 2, 3 and 4 - the third one must start on an even page and contains block 5 So, the knuth elements are divided into three different lists, each one with a variable storing the break value (respectively any page, odd page, even page). # I also tried two fo:blocks, first one with break-after=even-page and the # second with break-before=even-page, and I don't know exactly what the # result is supposed to be Both properties define the same break condition (4.8 in the recommendation): the first area generated by the second block must be leading in (i.e. start) an even page. One of the properties is redundant, the effect is the same as if only one of them were used, I think. # Also, a break-before=page on the very first block in the document seems to # be ignored. Is that correct behaviour? I think it is correct: the break condition requires the first area generated by the block to be leading in any page, and this is true even without adding an empty page. 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. # Interesting idea. The FLM may have more convenient access to the information # needed to deal with exactly this type of situation... at the very least, # it's worth considering moving part of the logic to FLM --say, storing a # state variable indicating whether the last page-break was forced or not-- so # the result of PSLM.needNewPage() would depend on FLM.needNewPage() which # would in its turn depend on 'lastPBForced'. # OTOH, this state variable could also be stored in the PSLM itself... 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. The method needEmptyPage() should return true only when we are starting the layout of a different subsequence, and the next page would not be of the right kind. For example: - the first subsequence creates an only page - when we start the pagination of the second subsequence (having break value odd page) we realize that the next page (#2) would not be ok, so we must add an empty one - if this subsequence creates more than a page, needEmptyPage must return always false (or maybe it should not be called) - needEmptyPage could return true (or be called again) only when we start the layout for the third subsequence, which must start on an even page. the FLM is the immediate LM child of PSLM, so it should have everything that PSLM does (except for the static content, which I don't think we care about when it comes to page breaking anyway.) Ideally, FLM should be the topmost LM that handles the page breaking, no? I wonder if the Knuth code should be out of PSLM completely I need some more time to reflect on this idea, but I write a quick answer anyway. My first impression is that I would find somewhat strange that the *page* breaking is not in the *Page*SequenceLM! :-) A more serious comment is that some formatting objects (footnotes and before floats) generates page-level-out-of-line-areas, whose placement, according to the recommendation (4.2.5), is controlled by the fo:page-sequence ancestor; so, if the PSLM must handle footnotes and before floats (influencing the available bpd for the normal areas) it must handle the whole page breaking process. Regards Luca
RE: Problems with break conditions and empty pages
-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 element of the BlockSequence)?
Or what about the following in AbstractBreaker.BlockSequence at line 64 :
endBlockSequence() {
...
returnSequence = new BlockSequence(startOn);
...
}
So, when BlockSequence.endBlockSequence() is called, the remaining
KnuthSequences are returned as a new BlockSequence with a startOn equal to
the value which was already set with the construction of the
sequence --maybe this simply needs to be changed to ...?
Cheers,
Andreas
RE: Problems with break conditions and empty pages
-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 the FlowLM was the place where the actual breakValue was resolved before it was passed to PSLM.needEmptyPage() or .needNewPage() --but looking closer, that's not how it works... (PSLM.handleBreak() is a private method). The method needEmptyPage() should return true only when we are starting the layout of a different subsequence, and the next page would not be of the right kind. Further browsing leads me to place my money on AbstractBreaker.BlockSequence. If I get it correctly, the 'startOn' value is set only once for the entire list (at construction time), but that value is returned every time the PSLM.PageBreaker calls BlockSequence.getStartOn() --which happens in PSLM.PageBreaker.startPart() line 205. So, if this method is called every time a new page is created, and *one* BlockSequence spans multiple pages, we would get the wrong breakValue for all pages but the first... Still looking for the optimal way to correct this behaviour. 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 element of the BlockSequence)? snip / [Glen :] the FLM is the immediate LM child of PSLM, so it should have everything that PSLM does (except for the static content, which I don't think we care about when it comes to page breaking anyway.) Ideally, FLM should be the topmost LM that handles the page breaking, no? I wonder if the Knuth code should be out of PSLM completely I need some more time to reflect on this idea, but I write a quick answer anyway. My first impression is that I would find somewhat strange that the *page* breaking is not in the *Page*SequenceLM! :-) A more serious comment is that some formatting objects (footnotes and before floats) generates page-level-out-of-line-areas, whose placement, according to the recommendation (4.2.5), is controlled by the fo:page-sequence ancestor; so, if the PSLM must handle footnotes and before floats (influencing the available bpd for the normal areas) it must handle the whole page breaking process. Both very good points! Let's keep it exactly where it is. Cheers, Andreas
Re: Problems with break conditions and empty pages
--- 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 divided into smaller arrays, with each smaller array undergoing its own Knuth page breaking process. (I prefer to think of areas being divided rather than FO's.) 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. 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. Actually, that is now available as a public accessor in the PageViewport object, so any LM working with one has access to the page number. And, within reason, accessors within PSLM could be used by FLM, which maintains a reference to its parent LM. the FLM is the immediate LM child of PSLM, so it should have everything that PSLM does (except for the static content, which I don't think we care about when it comes to page breaking anyway.) Ideally, FLM should be the topmost LM that handles the page breaking, no? I wonder if the Knuth code should be out of PSLM completely I need some more time to reflect on this idea, but I write a quick answer anyway. 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 to the formatting object (here, the page sequence), not the areas they generate. I was reminded a bit on that a few weeks ago by Andreas and Simon. You may recall, I recommended at the time that we have BodyRegionLM and a SideRegionLM instead of a FLM and a StaticContentLM. Under this scenario, PSLM controls complete page-by-page layout, and delegates to the BRLM and SRLM to do the body region or side areas. But if we have an FLM instead, my thinking is that it should perhaps process the entire fo:flow--including the creation of multiple page-viewport-areas in order to consume that flow. A more serious comment is that some formatting objects (footnotes and before floats) generates page-level-out-of-line-areas, whose placement, according to the recommendation (4.2.5), is controlled by the fo:page-sequence ancestor; I think this is because of the footnote and before-float separators (not the footnotes and before-floats themselves) which are defined in fo:static-content FO's under the page-sequences. The FLM somehow would have to be able to create these separators each time they are needed for each page. As for location controlled by the fo:page-sequence ancestor, that could simply mean that the fo:page-sequence defines the page margins and the side region dimensions. The footnote is just above the region-after, and before-floats are just below the region-before, hence the fo:page-sequence determines its location. This wouldn't necessarily mean that the actual layout of these objects needs to be done by the PSLM. so, if the PSLM must handle footnotes and before floats (influencing the available bpd for the normal areas) it must handle the whole page breaking process. Well, the available maximum bpd can be accessed from the area.BodyRegion child of the PageViewport--this value is calculated automatically upon initialization of a PageViewport. As you can see from section 6.10.1.3[1], these two areas consume space from the main-reference-area. So it appears that all that would be necessary is for the FLM to create a PageViewport, and if a flow has a before-float or footnote, reduce that bpd for the regular normal-reference-areas. (Also, to add the footnote/before-float separators in.) Actually, IMO right now, this work can be done by either PSLM or FLM. If the team's instincts are to remain with PSLM for this, that would OK with me. Thanks, Glen [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#pg-out-of-line
Re: Problems with break conditions and empty pages
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 a block on the middle of page *18* with a break-before value of even-page, FOP is supposed to render it at the top of page 20 instead. and 3.) The above processing is done only once for the fo:block with this property. I.e., assuming no child of fo:block has this property as well, if the block takes up multiple pages it will use pages 18-19-20-21-22..., for (1) above, and *not* 18-20-22-24... Thanks, Glen --- Luca Furini [EMAIL PROTECTED] wrote: 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 pages, while odd pages are empty; moreover, if the block with break-before is the first one in the document it is placed on the first page (which is odd!), without adding an empty page before. The same happens with break-after. I think this could depend on the conditions tested in the methods PSLM.needEmptyPage() and PSLM.needNewPage(); in particular, the first one should return false if the first page has already been created, while now it seems to return always true. I'll look at this again next week, obviously unless someone finds a fix before! :-) Regards Luca
Re: Problems with break conditions and empty pages
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, 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 a block on the middle of page *18* with a break-before value of even-page, FOP is supposed to render it at the top of page 20 instead. and 3.) The above processing is done only once for the fo:block with this property. I.e., assuming no child of fo:block has this property as well, if the block takes up multiple pages it will use pages 18-19-20-21-22..., for (1) above, and *not* 18-20-22-24... Thanks, Glen --- Luca Furini [EMAIL PROTECTED] wrote: 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 pages, while odd pages are empty; moreover, if the block with break-before is the first one in the document it is placed on the first page (which is odd!), without adding an empty page before. The same happens with break-after. I think this could depend on the conditions tested in the methods PSLM.needEmptyPage() and PSLM.needNewPage(); in particular, the first one should return false if the first page has already been created, while now it seems to return always true. I'll look at this again next week, obviously unless someone finds a fix before! :-) Regards Luca
RE: Problems with break conditions and empty pages
--- 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
properties
appear relevant only for fo:flow descendants.
Interesting idea. The FLM may have more convenient
access to the information
needed to deal with exactly this type of
situation...
Well, the FLM is the immediate LM child of PSLM, so it
should have everything that PSLM does (except for the
static content, which I don't think we care about when
it comes to page breaking anyway.) Ideally, FLM
should be the topmost LM that handles the page
breaking, no? I wonder if the Knuth code should be
out of PSLM completely, i.e., have FLM have this
method:
PageViewport[] generatePages(),
which would be called by PSLM, and once it returns,
PSLM then takes care of static content before sending
each page to the AreaTreeModel for rendering.
(Or, have the FLM feed the pages back to PSLM
one-by-one, after it finishes the flow for that page.
Same principle here--the FLM would do the breaking.)
Luca, Jeremias, WDYT?
at the very least,
it's worth considering moving part of the logic to
FLM --say, storing a
state variable indicating whether the last
page-break was forced or not-- so
the result of PSLM.needNewPage() would depend on
FLM.needNewPage() which
would in its turn depend on 'lastPBForced'.
OTOH, this state variable could also be stored in
the PSLM itself...
Roughly, the logic could become something like
PSLM.needNewPage(int breakVal) {
if( (curPage != null)
(curPage.getPage().isEmpty() ) {
if( breakVal == PAGE ) {
return (currentPageNum == 1);
} else {
boolean evenPage = (currentPageNum % 2 == 0);
return ((breakVal == (evenPage ? ODD_PAGE :
EVEN_PAGE)) ||
lastPBForced);
}
} else {
return true;
}
}
The logic is not as much a concern to me as its
location. This seems like it should ideally *all* be
in FLM. I would think FLM is to completely take care
of the fo:flow, including making 47 pages if need be,
doing the incrementing of columns within the span on
each page, etc. PSLM would just add the static
content after each page-viewport is returned to it by
FLM. I wonder if PSLM should be so designed that if
we had multiple ways to break up pages--it might mean
multiple FLM implementations, but PSLM would be the
same regardless.
Thanks,
Glen
