[Jeremias]
I think there is something fundamentally wrong with the layout dimension mechanism. I've found two problems, one minor, one very bad:
1. While implementing percentages for background-position-horizontal and -vertical, I realized that it wasn't so simple to base the calculation on a simple value. The percentage base is actually the padding-rect-size minus the intrinsic size of the background image. Of course, this value could be set by each layout manager but it seems awkward to have to do that everywhere. Instead, I can easily calculate this in TraitSetter.addBackground(), provided the BPD and IPD of each Area is properly set before calling TraitSetter.addBackground(). That's currently not the case, however. But it's probably a good idea to do that anyway.
Yes IPD and BPD traits should be assigned to all area which has ipd and bpd.
But at the time where base lengths is needed, no areas has yet been created. So I don't see any way to avoid making the base lengths available during getNextBreakPoss. Either as values in a HashMap or on demand via a context object.
2. The above let me calculate the background image position easily for block-containers. When I wanted to check the same for the body region I found some bugs that I'm not yet testing for. While trying to fix them I found a problem when I specify width=height="100% on a block-container as the only child of a flow. The BLOCK_IPD and BLOCK_BPD layout dimensions were fetched from the Root which returned the page size instead of the content-rect size of the current region body area (which is wrong for documents with different page sizes throughout the document). PageSequenceLayoutManager also sets the page size as BLOCK_IPD/BPD on each Region (which is wrong, too). In principle, the BLOCK_IPD/BPD should come from the currently applicable Region if there's no parent block-level object.
The current setting of dimension is neither complete nor correct.
I'm beginning to think that the layout dimensions should be held and provided
by the layout managers instead of the FObjs. To evaluate a
percentage-enabled value the layout manager would have to call
getLength()
Just to be accurate, I would say it is the getValue() call that must accept a context parameter.
with some kind of context object that allows it to fetch the right base values for percentage calculations. I haven't fully made up my mind about that and I'd like to hear what you guys think about this problem.
I agree completely.
The LayoutDimension in FObj was a hack to show off the relative length expression mechanisme. At the time a huge amount of Length.getValue() calls was located in PropertyManager. They are gone now, which I hope will make the change to using a context easier.
regards, finn
