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? <snip/> > > (more or less the effect the page-height property has on the > > page-viewport-areas generated during formatting) In that > > case, is it even conceivable to have more than one > > viewport-area for a block-container with constrained bpd? > > 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. > > Or would it mean that _all_ of them taken together should be > > _that_ big? > > The previously-cited 1.1 item seems to indicate that the constraint applies > to each of the viewport areas individually as opposed to all of them in > total. However, I could misunderstand. > > > Having no constraints on the keeps, and only the bpd > > specified, it seems perfectly legal to break and interpret > > the bpd constraint as a total that may be divided over > > multiple viewport areas, but it may seem a bit tricky. > > You may be right, but I can't think of a case where that would be useful. > > AFAICT, keeps and space constraints would be left intact for the contents of > the block-container. So, if a decision has been made that an additional > viewport is needed to fit the contents, the keeps, breaks, and spaces would > be used to decide which content went to an anterior vp and which to a > posterior vp, just like in any page-break decision. Hmm, seems like there's some room for interpretation. Yet another question for the FO WG. Sigh. I guess we're not so bad off with the current handling, so I'll let it be for the moment and go on to more important tasks. At any rate, this thread is flagged in my mail client... Thanks, Jeremias Maerki
