Border Painting

[Pierre-Henri Kraus <ph...@skynet.be>]

Hi, i got a few questions concerning the border painting...

Where does it actually takes places ? It seems it's done in 
AbstractPathOrientedRenderer, method DrawBorders(...) but then the 
collapsing border model should already be implemented (it checks if its 
the border is outer or not, and draw the border style which at been 
resolved at the layout stage). Is the border conflict resolving already 
done ? I've seen a few lines which seemed to do it fully (expect for 
spanned cells) in CollapsingBorderModelEyeCatching or something. I'm 
really lost...

Re: Border Painting

[Andreas L Delmelle <a_...@pandora.be>]

On Jul 2, 2006, at 15:27, Pierre-Henri Kraus wrote:

Hi Pierre-Henri,

> Hi, i got a few questions concerning the border painting...
>
> Where does it actually takes places ? It seems it's done in  
> AbstractPathOrientedRenderer, method DrawBorders(...) but then the  
> collapsing border model should already be implemented (it checks if  
> its the border is outer or not, and draw the border style which at  
> been resolved at the layout stage). Is the border conflict  
> resolving already done ? I've seen a few lines which seemed to do  
> it fully (expect for spanned cells) in  
> CollapsingBorderModelEyeCatching or something. I'm really lost...

ATM, for as far as the collapsing border model is already  
implemented, all resolving is done during the layout-phase. I guess  
this corresponds to what you see in CollapsingBorderModelEyeCatching.

I have already taken a few steps (still only locally, since it's far  
from complete) to perform part of the resolving even earlier --as the  
FOTree is built-- and expose a few methods to the layoutengine to  
deal with the remainder (borders on spanned cells and page- or column- 
breaks).

My main reason for wanting to move in that direction is the fact that  
the collapsing border model rules are defined independently of any  
pagination, so by itself the logic to perform the border-resolving  
does not need page-breaking context, not even the side is relevant  
(the border-specs and -precedences suffice to make the decision which  
border will win)

IOW: resolving borders does not --at least not fully-- strike me as a  
layout-task. I'm certain that it is possible, in the case of a small  
table that does not span across multiple pages, to do *all* of the  
resolving before the layoutengine kicks off. The possibility of page- 
breaks occurring only places a limitation on the extent to which this  
can be dealt with in the FOTree. If you'd take start/end borders, for  
example, these would be completely resolvable without any need to  
look at the page-breaks (depending on reference-orientation?)

The actual border *painting* is done by the renderer, and ideally,  
the renderer should not need to concern itself with border-resolving  
anymore. It should just render the border-segments as they are  
presented by the layout-engine (for the renderer-types that use the  
FOTree, that is...)

HTH!

Cheers,

Andreas