Finn Bock wrote:
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.


Reply via email to