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.
It prevents overlapping/concurrent runs. Whether these are useful is quite another matter.Advertising
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.
Given that there is a LM class for each FO class, and a LM object for each FO which basically duplicates most of the FO data, I don't think the three additional LM classes count all that much. And I'm not sure why it's an advantage to separate layout logic from the FO tree while the FOs are still used to store transient data used in the layout process. Code reuse is an issue, but it can also be solved through delegation. The real benefit of separating LM and FO would be pluggable layout engines, but I have the feeling this would also collide with using the FOs as storage for some layout process data.
I don't know what splicing means,
<fo:block id="a" border-start-width="1mm+10%"> <fo:block id="b" border-start-width="10mm +my:get('a:border-start-width)"> (I have to make up a function because a quick check of section 5.10 indicates there is *no* function which returns the unresolved value, contrary to what I seemed to remember) The b block border-start-width is parsed into a tree plus +-- 10mm +-- my:get and after the arguments of the function has been parsed, the calling node is replaced with the parsed tree of the a block property: plus +-- 10mm +-- plus +-- 1mm +-- 10% This can be folded into plus +-- 11mm +-- 10% if someone feels like implementing constant folding. The 10% will be resolved when the b block LM looks for break positions, as usual.
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.
Wild pseudocode getNextBreak(LayoutContext lc) { ... BorderAndPadding bp = propMgr.get(lc); // get and resolve ... LayoutContext childLC = new LayoutContext(...) childLC.setBorderAndPadding(bp) // or pass it elsewhere childLM.getNextBreak(childLC);
Setting *all* potentially inheritable properties (inheritable via 'inherit', not necessarily automatically inheritable) may be a bit clumsy, but there could be some refactoring to bundle it otherwise, or even that new LayoutContext(propMgr,lc) creates all resolved properties in the new layout context.
I'd be +0 to volunteer <wink> somebody to implement that.Me too :-)
Should we delay my proposed patch until somebody has come up with an implementation that pass the LayoutContext to all Length.getValue(lc) calls?
I don't see much value in delaying your patch, but let's keep an eye (or bugzilla entry) on this issue.
J.Pietschmann
