[Finn Bock]
I don't understand how you propose to solve any of this, but I hope it would be Ok to commit the straight forward solution I propose.
[J.Pietschmann]
Whatever works. I just want to note that given the almost one- to-one correspondence between FOs and LMs both in classes and instances (with the exceptions of page, column and line LM), the only advantages of having LMs is - code reuse by inheritance - no layout related data in the FO, for better sharing/reuse Keeping area dimensions in the FO kills the latter.
That is not correct. Temporarily storing the area dimension in the FO tree just long enough for the getNextBreakPoss() to return does *not* in any way prevent reusing the FO tree or the LM tree for an other rendering run.
There is also more good reasons for having an LM tree than just code reuse. The lineLM and a separate place for the layout logic just to name two.
For storing reference measurements for resolving in the layout
context, you have only to keep track of inheritable properties,
which are basically font-size, ipd and bpd. References to
specified values (in contrast to computed values) can be handled
by splicing in the parsed property expression for the referenced
property as replacement for the referencing function.
I don't know what splicing means, but the issue that I don't understand your solution to is when a child fo makes a reference to an computed value that is an expression (like "10% of IPD of 'a'") in a parent fo.
<fo:block id="a" border-start-width="10%"> <fo:block id="b" border-start-width="inherit">
</fo:block> </fo:block>
This way the FO tree holds properties (parsed property expressions), while the layout context and the area tree hold the refined traits.
I propose to store the specified expression (the "10% of IPD of 'a'") in the parent fo. But if that design is chosen, any reference to that property in the parent fo must ensure that the base value that is in effect for the parent fo is available.
The base values for the parent fo (IPD of 'a') is not currently available in the layout context for 'b'. Only the IPD of 'b' value exists in the LayoutContext for 'b'. And there is not even a single area created yet.
Using the LayoutContext would be a clean design, but first the LayoutContexts must be linked together with the LayoutContext from the parent fo and the LayoutContext must have a reference to the fo element so that the LengthBase can decide how far up the LayoutContext chain it should go in order to find the base value that is valid for the parent fo.
I'd be +0 to volunteer <wink> somebody to implement that.
Should we delay my proposed patch until somebody has come up with an implementation that pass the LayoutContext to all Length.getValue(lc) calls?
regards, finn
