On Thu, Feb 19, 2004 at 08:52:41AM +0100, Finn Bock wrote: > If an expression reference another expression in a parent fo, the parent > fo expression must be evaluated against the LayoutContext that was in > effect for the parent fo and *not* against the child fo LayoutContext. > > <fo:block id="a" border-start-width="10%"> > <fo:block id="b" border-start-width="inherit"> > > </fo:block> > </fo:block> > > It must be the LayoutContex for 'a' that is used when we evaluate the > 10% even when we call: > propertyList.get(PR_BORDER_START_WIDTH).getValue(lc) > with the layout context for 'b'.
The present code contains a partial implementation of percent based properties, e.g. in fo:leader, leader-length. This implementation indeed uses the context layout for the base dimensions with respect to which a relative property is calculated. The ipd of the containing block is retrieved from it and is propagated to the method that calculates the actual leader length: LeafNodeLayoutManager.getNextBreakPoss: ipd = getAllocationIPD(context.getRefIPD()); AddLMVisitor.getLeaderAllocIPD: node.getLength(Constants.PR_LEADER_LENGTH | Constants.CP_MAXIMUM, ipd); Leader.getLength: length = (int)(((PercentLength) maxlength).value() * dim); where dim = ipd = context.getRefIPD(). I realized that this is wrong for exactly the above reasons. If the percent expression is specified on an ancestral FO, the current implementation fails to see this and always calculates it on the basis of the ipd of the current containing block. See this example: <fo:flow flow-name="xsl-region-body"> <fo:block leader-length="30%" leader-pattern="rule"> <fo:leader/> <fo:block margin-left="60pt" margin-right="60pt"> <fo:leader/> <fo:block>This is a block with a leader and a block with left and right margins of 60pt. The latter block contains a leader and this text. The leader length is specified as 30% on the topmost block.</fo:block> </fo:block> </fo:block> </fo:flow> The 30% must be calculated w.r.t. the page width for both leaders, and both leaders must be equally wide. This is not the current result. When I tried to remedy this, I got confused by the sets of symbols on PercentBase and on LengthBase. Why are there 2 sets of symbols? They are mapped onto each other in LengthBase.getBaseLength(), but not all symbols are mapped, e.g. LengthBase.CONTAINING_BOX, which is used by leader-length, has no corresponding action. Some further integration of old and new code must be done here. Question: What to do if I insert a fo:wrapper between fo:flow and fo:block? That makes it the parent of fo:block, but it has no layout manager corresponding to it. Override getLayoutDimension on it? > But for now I think we should just use the FO tree and later change the > signature of getValue() to take some kind of context parameter when a > real need arise. I agree. I am now convinced that your solution is simple, practical and robust. You demonstrated that it deals properly with FOs that generate more than one area. You also demonstrated that the LayoutContext idea is insufficient. Holding layout information in the Layout Managers is more pure, but indeed not absolutely necessary. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl