Team, 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. 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. 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() 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. Jeremias Maerki
