Jeremias Maerki wrote: > 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.
You have hit on one of the many reasons that I think a modular approach is so important, and why I think FOP is *still* not ready to even attempt to rewrite layout, and why not binding the property values is useful (I am not sure that it is required, but useful). The Foray approach to the issue is that such a value is computed in the Area Tree. The FOTree computes what it can, but in such cases, it needs a dimension passed to it in order to be able to complete the computation. Any point in time that this dimension is needed, the related Area has been created. The layout system calls area.traitBackgroundPositionVertical(), which calls getGeneratedBy().traitBackgroundPositionVertical and passes the needed dimension(s) back to it. I HTH. It probably seems like I am beating a dead horse. That is not my intention. I just think it has to be really frustrating to try to write layout code when your FOTree and AreaTree issues are not resolved. I admire those who try, but ... Victor Mote
