> -----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 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? (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? 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. Greetz, Andreas
