Jeremias Maerki wrote:

> Thanks to Victor and Andreas for helping me here, although 
> I'm still confused.
> On 27.01.2005 00:25:27 Victor Mote wrote:
> > Andreas L. Delmelle wrote:
> > 
> > > Do you feel the contents of the block-container should 
> not be broken 
> > > up at all? (Hence the analogy to a fo:external-graphic?)
> > 
> > No, sorry, I didn't mean to imply that. I think the contents can 
> > (possibly, depending on the overflow constraints) be broken up, but 
> > that the viewport cannot be. So the analogy with external-graphic 
> > breaks down there. The similarity is in the fact that they (in this 
> > case) have a fixed size and must move in their entirety.
> This seems to be contradicting. I don't see how the overflow 
> property would control such behaviour. Also, if you say that 
> they "must move in their entiretly", how can the contents be 
> broken up? Or does "they"
> refer to something else than the contents?
I'll try to clarify what I mean. A distinction must be made between the
viewport area(s)that are created by the block-container, which I will call
the container areas, and the areas that are generated by the children of the
block-container (block-level FOs), which I will call the child areas. Each
viewport area is a fixed size in the scenario described. It cannot be split
between columns or pages. If there is not room for it in its entirety on
page n, it must be moved in its entirety to page n + 1. However the child
areas are free to flow between the container areas, just like they would
flow between the main-reference-areas on two pages. So a block inside the
block-container might have part of its contents in one container area and
part in a subsequent one.

The overflow property enters in because of the "Issue" that you mentioned
(1.1 Standard, Section 6.5.3): "<p>The overflow property applies to this
formatting object. There is a question of interpretation on whether the
fo:block-container generates more than one area when the
block-progression-dimension is fixed.</p> <p>The change proposed here
requires the user to specify the "repeat" value for the overflow property
when they want multiple instances of the block-container rather than the
initial value for overflow.</p>"

The default value for overflow is auto, which probably results in contents
being clipped for printed media (there being no opportunity for a
scroll-bar). But if the user sets the value to "repeat", additional content
areas can be created to contain the overflowed content. If the overflow
settings are such that overflowed content has no place to go, then
conceptually it all stays in the one container area, and is clipped. So the
setting of the overflow value on the block-container directly affects
whether those contents might be split between two container areas or simply

You are correct that "they" in my original post did not refer to the child
areas, but rather to the container areas. My apologies for the ambiguity.

> > Yes. This seems most useful to me in cases where the viewport would 
> > occupy most or all of the main-reference-area, as in the 
> case of the 
> > report-turned-sideways example I gave earlier. Suppose you 
> have some 
> > unknown quantity of 132-column output you want to show in landscape 
> > mode. You can create a fixed-size block-container, tell it 
> to overflow 
> > into other ones, add a "break" constraint at the end of 
> each page, and 
> > you now get n pages of output.
> Well, this is a case where I'd rather use a separate 
> page-sequence with the reference orientation set on the 
> simple-page-master.

Fair enough. Here are some things to consider:
1. I think using a block-container gives you the *potential* option of
letting the viewports be out-of-line areas. So your content might read: "See
Listing 1 <fo:block-container ... </fo:block-container>, where the effects
of this ..." The content continues, but perhaps the next 3 pages are filled
with the block-container contents. I am not yet convinced that I fully grasp
all of the implications of the ordering issues, so it may be that this isn't
supported by the Standard.
2. What if the requirement is that 2 portrait "pages" be turned 90 degrees,
side-by-side, on the now landscape page? Depending on the amount of room on
the first page, and the parity of the number of such pages, you might end up
with an empty half-page. If your content needs to continue (as opposed to
looking like a new chapter), the repeating block-container looks like a good

Victor Mote

Reply via email to