On Mar 21, 2007, at 22:06, Jeremias Maerki wrote:
[Me: ]
<snip />
Seems my proposed fix (bugzilla 41894) goes in the right direction.
I agree.
Only it does not take reference-orientation and/or writing-mode into
account when mapping width/height to ipd/bpd... but that seems to me
currently a part of a larger problem. At certain places in the code,
nothing but ipd/bpd is used. Then at other places, we get explicit
references to width/height. I'm thinking of moving this logic to the
fo tree/property side. The layoutengine should work entirely with ipd
and bpd, if only to give the /impression/ of consistency... ;-)
Agreed, that part is still in need of improvement. Remember the
post on
fop-users of a user who wanted to rotate the column headings of a
table
by 90° and had to resort to SVG? That's actually something that
IMO, the
block-container could and should do. And it's exactly where FOP
currently fails to behave.
Looking further into this, I can see the difficulties.
A region on one page can have a different reference-orientation/
writing-mode than on the preceding or following page, and it's
precisely those that form the basis on which the mapping of height/
width should be made.
From the point of view of the higher-level LM, the height of an
absolute-positioned block-container is the block-progression-
dimension if the block-container's reference-orientation and writing-
mode are the same(*) as that of the particular region it ends up on.
If not, then everything is re-evaluated. height becomes ipd, top
becomes after, left may become end...
In a certain sense, it even seems that one could say that the
specified value for block-progression-dimension may turn out to be
what the higher level LM needs to consider as the inline-progression-
dimension of the child area. Correct?
(*) reference-orientation could also differ by 180 for height/width;
for top/right/bottom/left this would make a difference however...
Analogous for the writing-mode's difference between lr-tb and rl-tb
Cheers,
Andreas
