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.
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.
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. This way the FO tree holds properties (parsed property expressions), while the layout context and the area tree hold the refined traits.
J.Pietschmann
