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

Jeremias Maerki

Reply via email to