> -----Original Message-----
> From: Victor Mote [mailto:[EMAIL PROTECTED]
> Sent: woensdag 26 januari 2005 21:49
> Just to be clear (not argumentative), I was saying something quite
> different. For the example that Andreas has given, my
> understanding is that there would only be one child
> viewport area, containing the entire contents of both blocks,
> but that it would be pushed onto the following column/page.
Do you feel the contents of the block-container should not be broken up at
all? (Hence the analogy to a fo:external-graphic?)
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
- a default of keep-together="auto"
> The user has dogmatically told us how big the viewport(s) should be.
"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?
(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
Or would it mean that _all_ of them taken together should be _that_ big?
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.
One block-container having two vpa's for two rectangles over two pages. Its
children generating a possible total of three areas, two of which are inside
the vpa for the rectangle on the first page.