On 26.01.2005 18:43:58 Victor Mote wrote: > Jeremias Maerki wrote: > > > Now, I've got a different problem. I run accross a bug in > > layout concerning block-containers with height/BPD specified > > (absolute-position="auto"). I tried to fix it but I can't > > find the passage in the spec that tells me how to deal with > > the space that is not allocated by descendant FOs inside the > > block-container. > > > > Is this space considered as part of the padding-after, and if > > yes with what conditionality? > > BPD and IPD both specify the size of the content-rectangle, so no part of > unused BPD could be considered part of padding.
Makes sense. > > The problem is page/column breaking. Normal blocks can be > > broken between lines which is probably also the case for > > plain block-containers (no properties specified). But as soon > > as the BPD is predefined > > (autoheight=false) it is unclear to me how to handle it. > > > > I also saw that in the 1.1 WD there is an issue (see > > block-container) that may be related to this, but it didn't help. > > I'm not sure I understand the question or know the answer. What I think you > have described is an area with an absolute size and a relative position that > does not fit in the current column or page, but that may not use all of the > available BPD. Regardless of how well the contents fit inside the area, > doesn't such an area have to be forced to the next page or column (unless it > floats and can be moved so that it does fit)? The 1.1 spec (6.5.3) clarifies > this a bit by saying "All generated viewport-areas are subject to the > constraints given by the block-progression-dimension and > inline-progression-dimension traits of the fo:block-container". I take this > to mean that a block-container might generate more than one such > viewport-area if the contents are too big to fit into one (subject to the > 1.1 issue that you mention), but that, in any case, if the contents are too > small, the generated viewport-area must meet the IPD and BPD constraints. > The user can specify IPD and BPD as <length-range> if they want to allow the > rectangle some flexibility in how it is sized. > > HTH. It does, at least a bit. Anyway, maybe I should ask the question in a different way: Given a block-container where the BPD is specified, are its children subject to column/page breaking if the whole block-container doesn't fit into the available area in BP direction? If yes, how is the remaining space in BP direction which is not taken up the BC's children to be handled? The quote you provided above probably point in the right direction. But I guess my problem is that I haven't found the part of the spec, yet, that establishes this constraint for block-progression-dimension. I've searched the spec back and forth and haven't found anything. After a lot of thinking I believe it's chapter 4.3.2 "Overconstrained space-specifiers", but I don't understand how this explains whether to do breaking inside the block-container or not. Thanks, Jeremias Maerki
