On 23.08.2005 21:01:13 Andreas L Delmelle wrote:
> Hash: SHA1
> Hi all,
> Back from holiday, and just started work on the collapsing border model 
> (something I discussed thoroughly with Jeremias a while ago --don't 
> worry, I'm not going to start all over :-) ) Let me just say that, 

Wohoooo! Thanks for taking this not quite trivial task upon yourself.
You know we're going to be heroes if we get the collapsing border model

> where earlier on I didn't have a clear idea on what needed to be done 
> code-wise, right now I'm pretty confident that I will be able to offer 
> a patch-proposal very soon...

Can't wait!

> Note that, although it will mean that part of the border-collapsing 
> logic will move to the FOTree, I'm still convinced this will make the 
> related code in layout much easier to follow --but to get the FULL 
> picture, potential devs will need to look at both the FOTree AND the 
> LayoutManagers.

That's ok.

> On to the topic then: while I'm at it, I would also like to try and 
> implement the border-precedence properties (and ultimately also 
> collapse-with-precedence), and have the following questions/remarks 
> about this:
> * What would be the correct property type to use? So far my working 
> hypothesis is 'EnumNumber', since the value can be an enum (=force), as 
> well as any integer value. Correct assumption?

I think it would be a normal NumberProperty to which you add enums by
calling addEnum().

...but IANFOTS = I am no FO tree specialist. :-)

> + Another question concerning the possible value of 'inherit': does it 
> suffice to have Maker.setInherited() set the flag to true (in 
> FOProperyMapping)?

No, the border precedence properties are not inherited. I think the
"inherited" value is automatically handled. You don't need to do
anything special.

> * Another issue may be that those properties' default values depend on 
> the type of object they are bound to. The most straightforward way of 
> dealing with this seems to be to defer determining the actual default 
> value until the respective FObj's bind() methods...
> Does this sound OK, or does anyone see a better way? I know every 

Can't tell. Sorry.

> PropertyList holds a reference to its parent FObj, but checking the 
> runtime-type of that FObj for each of the individual PropertyLists 
> seems a rather cumbersome approach. I somehow feel it would be tidier 
> if we use the FObj class hierarchy here, and let each subclass decide 
> for itself what default value to assign if the value is "none" at that 
> point ("none" = the default that is set in FOPropertyMapping)
> * In the table objects' bind() methods, I was thinking of reading these 
> from the property list into a small array, where the indices correspond 
> to constant values for the four sides --the ones defined in 
> CommonBorderPaddingBackground?--, so that layout can conveniently 
> access the precedence values through a method like:
> public int getBorderPrecedence(int side) {
>      return borderPrecedence[side];
> }
> Comments/suggestions welcome.
> That's it for now.

Good luck!!!

Jeremias Maerki

Reply via email to