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.

> As an attempt to clarify:
> I wasn't 100% certain, but IIC, not breaking the 
> block-container between the two blocks would come down to 
> having default constraints for the keep-* properties (initial 
> value other than "auto")
> Very rough interpretation of how I read it, for the block-container :
> - keep-with-previous="always" (only in case one of its 
> children returns a reference-level-out-of-line area ~ 
> side-float|absolute) or "auto" (in all other cases)
> - a default of keep-together="auto"
> > The user has dogmatically told us how big the viewport(s) should be.
> More precisely:
> "The user has dogmatically told us the constraints to which 
> all viewport-areas generated by the block-container are subject."
> Would this mean that _each_ generated viewport-area has to be 
> _that_ big?

Yes (if I am right). They can choose not to constrain it at all, or they can
constrain it flexibly with a <length-range>. The fact that they have rigidly
specified the value indicates that they want it to be that size.

> (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

> 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.

Victor Mote

Reply via email to