On 23.08.2005 21:01:13 Andreas L Delmelle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
working!

> 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