Peter B. West wrote:

> depend on the type supported by the Property.  Take MaxWidth.  What
> value will be returned?  An int, representing the number of millipoints?
>   An Integer?   A Length object?  What happens when the width is, as
> yet, unresolved, because it depends upon the resolution of the width of
> a reference area in the Area Tree?  The value is not undefined, just
> unresolved.  When the FO Tree interacts with the Area Tree, the length
> will be resolved.  But the Area Tree may be re-laid, in which case the
> value will revert to unresolved.

This is a good question. The answer to the first part is that it should
return an int, representing the number of millipoints. When it cannot be
resolved, it should return an int constant TBD_LAYOUT (or whatever), which
is equal to -32,987 (or whatever). So, the Area Tree or Layout needs to then
perhaps query another "get" method to determine how it should compute the
value from its Area Tree context, or, as I mentioned in a recent (within the
past hour or so) posting in response to Glen, either 1) passing context data
to "get", or 2) making "get" look at the area tree context before returning
the value. The second of these requires making the FO Tree nodes know about
their Area Tree children. Each node in the Area Tree not only has a parent,
and possible siblings, and possible children in the Area, but also has a
parent in the FO Tree. Each node in the FO Tree can therefore know what its
children in the Area Tree are as well.

> The resolution of properties within the FO Tree has dependencies on the
> resolution of areas in the Area Tree.

Do you like any of the 3 possibilities above as potential solutions? And,
importantly, are there ways that your work can help us implement any of
this? I know you have a huge investment in trying to solve this problem,
and, although I don't "get" all of it, I want to make sure that 1) all of
your concerns are addressed, and 2) as much of your work is used in the
solution as possible.

Victor Mote

Reply via email to