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 clipped. 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 option. Victor Mote
