On 22.03.2007 11:41:28 Vincent Hennebert wrote: > Hi, > > A small question: am I true that the element list passed as parameter of > the SpaceResolver.resolveElementList method should be delimited by > reference areas? > That is: as there is a fence before (and after) a reference area, there > will never be stacking constraints crossing ref-areas's boundaries.
Yes. > AFAIU the SpaceResolver assumes that there is no ref-area generated by > any element of the list it's working on. The SpaceResolver itself doesn't care about reference areas. It assumes that it is passed the right element lists. :-) Space resolution never goes beyond reference area boundaries except for a block-container with absolute-position="auto" and block-progression-dimension="auto" which is currently (probably) handled wrongly WRT space resolution. A normal auto-height block container currently behaves similar to a block which is actually wrong (probable bug). > This raises the question as to how retained borders and paddings are > handled: their widths will count in the penalty width of resolved break > elements. How are borders from elements surrounding the list handled? > > Example: > <fo:block border-after-width.length="4pt" > border-after-width.conditionality="retain" > border-after-style="solid" border-after-color="red"> > <fo:block-container> > <fo:block border-after-width.length="4pt" > border-after-width.conditionality="retain" > border-after-style="solid" border-after-color="blue"> > some text... > </fo:block> > </fo:block-container> > </fo:block> > > IIUC the element list will be cut at the beginning of the > block-container. Not cut. BlockContainerLM starts a new element list. > How will the red border of the enclosing block be taken > into account in the penalties produced by SpaceResolver on the list of > elements inside the block-container? Not at all, since they don't interact according to the rules in 4.3.1: http://www.w3.org/TR/xsl11/#area-space Jeremias Maerki
