SpaceResolver usage

[Vincent Hennebert <vi...@anyware-tech.com>]

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.
AFAIU the SpaceResolver assumes that there is no ref-area generated by
any element of the list it's working on.
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. 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?

Thanks,
Vincent

Re: SpaceResolver usage

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 23.03.2007 11:49:20 Vincent Hennebert wrote:
<snip/>
> >> 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
> 
> Well, the width of the border from the outer block must still be
> considered. IIUC the inner block generates pending elements for its
> border-after, which will be converted by SpaceResolver into a Knuth
> penalty at each legal break of the sequence it generates, with a penalty
> length equal to the border width.
> At the outer block level, each penalty from subsequences must be
> modified to also take the border-after of the outer block into account.
> At least that's a way to implement things. Is that actually implemented
> that way?

More or less but not explicitely, rather implicitely. As I said, normal
block-containers are not implemented correctly right now. It doesn't
create a new element list but behaves like a normal block which causes
the fence to be ignored. The result otherwise is often like expected,
even your border is probably handled correctly in many cases. That's
probably the reason nobody has yelled until now. I always knew there was
something not quite right there. The problem is documented here (from disabled-testcases.xml):
Auto-height block-containers produce fences (block-container_space-before_space-after_3.xml)
    * Block-containers with no height currently don't
          create a fence for spaces as they should (they behave like a
          normal block).

Anyway, I suggest you write a test case for your scenario so we can all
verify that we all have the same expectation and to document a possible
problem with those penalties. Even if only to make sure that this is
handled properly when/after the above bug is fixed and your point may
have been forgotten.


Jeremias Maerki

Re: SpaceResolver usage

[Vincent Hennebert <vi...@anyware-tech.com>]

Hi,

Jeremias Maerki a écrit :
> On 22.03.2007 11:41:28 Vincent Hennebert wrote:
>> Hi,

<snip/>

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

Ok.


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

Well, the width of the border from the outer block must still be
considered. IIUC the inner block generates pending elements for its
border-after, which will be converted by SpaceResolver into a Knuth
penalty at each legal break of the sequence it generates, with a penalty
length equal to the border width.
At the outer block level, each penalty from subsequences must be
modified to also take the border-after of the outer block into account.
At least that's a way to implement things. Is that actually implemented
that way?

Vincent

Re: SpaceResolver usage

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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