Andreas L Delmelle wrote:
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, 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...
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
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
* 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?
The type should be a number with added 'force' enum. The number property
will then coerce a 'force' value into an EnumNumber which is a number
that also holds a enum value, but only the property subsystem needs to
+ Another question concerning the possible value of 'inherit': does it
suffice to have Maker.setInherited() set the flag to true (in
* 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?
It was my goal that all the properties should return the correct value
from the PropertyList. So if it is possible at all, I would prefer to
see that the inheritance issues is implemented in the PropertyMaker
classes, instead of the FObjs (or the LayoutManagers).