From 52bc8077df0ac367a063f95b6c62f3595ac47714 Mon Sep 17 00:00:00 2001 From: Simon Pepping Date: Tue, 1 Mar 2005 20:47:48 +0000 Subject: [PATCH] Patch 33597 by Renaud Richardet, and a few other edits git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@198461 13f79535-47bb-0310-9956-ffa450edef68 --- .../content/xdocs/DnI/areatree.xml | 4 +- .../content/xdocs/DnI/getnextbreakposs.xml | 125 ++++++++---------- 2 files changed, 55 insertions(+), 74 deletions(-) diff --git a/src/documentation/content/xdocs/DnI/areatree.xml b/src/documentation/content/xdocs/DnI/areatree.xml index f3ab7a2b7..1b8b93dfe 100644 --- a/src/documentation/content/xdocs/DnI/areatree.xml +++ b/src/documentation/content/xdocs/DnI/areatree.xml @@ -113,7 +113,7 @@ main[1] dump pageSLM
Overview - Create the layout (doLayout) + Create the layout (activateLayout) First create a new Page Viewport (makeNewPage). @@ -203,7 +203,7 @@ single flow area without children. [2] org.apache.fop.layoutmgr.PageLayoutManager.createPageAreas (PageLayoutManager.java:805) [3] org.apache.fop.layoutmgr.PageLayoutManager.createPage (PageLayoutManager.java:748) [4] org.apache.fop.layoutmgr.PageLayoutManager.makeNewPage (PageLayoutManager.java:467) - [5] org.apache.fop.layoutmgr.PageLayoutManager.doLayout (PageLayoutManager.java:220) + [5] org.apache.fop.layoutmgr.PageLayoutManager.activateLayout (PageLayoutManager.java:220) diff --git a/src/documentation/content/xdocs/DnI/getnextbreakposs.xml b/src/documentation/content/xdocs/DnI/getnextbreakposs.xml index 96bd64390..122e10b75 100644 --- a/src/documentation/content/xdocs/DnI/getnextbreakposs.xml +++ b/src/documentation/content/xdocs/DnI/getnextbreakposs.xml @@ -103,55 +103,39 @@ FO nodes? Child layout managers are created and retrieved in the method AbstractLayoutManager.getChildLM. -The layout manager has a layout strategy, which has an -AddLMVisitor object, which is responsible for -creating layout managers for the FO nodes. - -The layout manager gets the layout manager for its next child from its -LMIter object childLMIter. This -LMIter object contains an iterator over the -children of the layout manager's FO node. It behaves itself as an -iterator over the list of layout managers for the children. It -constructs those layout managers when needed, in its -preLoadNext method. It does so by calling the -layout strategy's AddLMVisitor object's -addLayoutManager method. The -LMIter object gets the layout strategy via the -current layout manager, which it knows. - -AddLMVisitor's addLayoutManager -method first registers the LM list in its second argument, i.e. the -LMIter object's LM list, as its own member -currentLMlist. Then it asks the FO node to accept -it as the FOTreeVisitor -(acceptVisitor). The FO node then calls the -appropriate method of this FO tree visitor, in this case -(fo:flow) the method serveFlow -(AddLMVisitor.serveFlow). This method creates a -FlowLayoutManager object and adds it to the -currentLMList. Thus LMIter has a -layout manager for its next child. It returns this layout manager in -the call to its next() method, when the current -layout manager invokes its getChildLM method. - -Note that layout manager types may have their own subclass of -LMIter, -e.g. BlockLayoutManager$BlockLMiter and -AbstractList$ListItr, which may implement a -different method of creating child layout managers. - -The method acceptVisitor of the FO node calls the -appropriate method of its visitor. This procedure effectively -implements an indirect mapping from FO node type to layout -manager. The indirection allows the AddLMVisitor -object to return its own layout manager for each FO node type. Because -the AddLMVisitor object is part of the layout -strategy, this indirection allows the layout strategy to provide its -own layout managers for the layout process. In this manner, a -different layout strategy can be coupled to the other parts of the -program. - -Note that AbstractLayoutManager.getChildLM itself +The layout manager gets the layout manager for its next child +from its LMIter object +childLMIter. This LMIter object +contains an iterator over the children of the layout manager's FO +node. It behaves itself as an iterator over the list of layout +managers for the children. It constructs those layout managers when +needed, in its preLoadNext method, which calls the +convenience method preLoadList. Using the iterator +fobjIter, preLoadList iterates +through the children of the current FO-Object and preloads the +corresponding LMs +(LayoutManagerMaker.makeLayoutManagers()). Thus +LMIter has a layout manager for its next child. It +returns this layout manager in the call to its +next() method, when the current layout manager +invokes its getChildLM method. + +BlockLayoutManager.ProxyLMiter has +its own subclass of LMIter, which implements a +different method of creating child layout managers. See the next +section. + +The method that creates the LMs, +LayoutManagerMaker.makeLayoutManagers(), is +implemented by FOP's implementation of the +LayoutManagerMaker interface, +LayoutManagerMapping. A different LM system can be +hooked into FOP by inserting a different implementation of the +LayoutManagerMaker interface. (See +FOUserAgent.setLayoutManagerMakerOverride.) + +Also note that AbstractLayoutManager.getChildLM itself does not behave as an iterator. The current child layout manager is returned until it is finished. One can safely make multiple calls to getChildLM. If the current child layout manager is @@ -169,41 +153,38 @@ is used in BlockLayoutManager.getNextBreakPoss. AbstractLayoutManager.getChildLM: - [1] org.apache.fop.layoutmgr.AbstractLayoutManager.<init> (AbstractLayoutManager.java:71) - [2] org.apache.fop.layoutmgr.BlockStackingLayoutManager.<init> (BlockStackingLayoutManager.java:70) - [3] org.apache.fop.layoutmgr.FlowLayoutManager.<init> (FlowLayoutManager.java:81) - [4] org.apache.fop.layoutmgr.AddLMVisitor.serveFlow (AddLMVisitor.java:894) - [5] org.apache.fop.fo.pagination.Flow.acceptVisitor (Flow.java:187) - [6] org.apache.fop.layoutmgr.AddLMVisitor.addLayoutManager (AddLMVisitor.java:198) - [7] org.apache.fop.layoutmgr.LMiter.preLoadNext (LMiter.java:88) - [8] org.apache.fop.layoutmgr.LMiter.hasNext (LMiter.java:77) - [9] org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM (AbstractLayoutManager.java:186) - [10] org.apache.fop.layoutmgr.PageLayoutManager.getNextBreakPoss (PageLayoutManager.java:253) - [11] org.apache.fop.layoutmgr.PageLayoutManager.doLayout (PageLayoutManager.java:228) + [1] org.apache.fop.layoutmgr.LayoutManagerMapping.makeLayoutManagers(org.apache.fop.fo.FONode, java.util.List) line: 140 + [2] org.apache.fop.layoutmgr.PageSequenceLayoutManager(org.apache.fop.layoutmgr.AbstractLayoutManager).preLoadList(int) line: 399 + [3] org.apache.fop.layoutmgr.PageSequenceLayoutManager(org.apache.fop.layoutmgr.AbstractLayoutManager).preLoadNext(int) line: 409 + [4] org.apache.fop.layoutmgr.LMiter.hasNext() line: 39 + [5] org.apache.fop.layoutmgr.PageSequenceLayoutManager(org.apache.fop.layoutmgr.AbstractLayoutManager).getChildLM() line: 168 + [6] org.apache.fop.layoutmgr.PageSequenceLayoutManager.getNextBreakPoss(org.apache.fop.layoutmgr.LayoutContext) line: 260 + [7] org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout() line: 232
-
+
Block layout managers and their child layout managers -Block LMs are different in their treatment of their child LMs. For -this purpose BlockLayoutManager defines a nested class BlockLMiter, -which is a subclass of LMiter. +Block LMs are different in their treatment of their child +LMs. For this purpose BlockLayoutManager defines a +nested class ProxyLMiter, which is a subclass of +LMiter. -A BlockLMiter object has a member called proxy, -which is the basic LMiter over the children of the -block. If the proxy produces a child LM that does not generate inline -areas, the child LM is added to the list of child LMs as normal. But -if the childLM generates an inline area, a new +This proxy is the basic LMiter over the +children of the block. If the proxy produces a child LM that does not +generate inline areas, the child LM is added to the list of child LMs +as normal. But if the childLM generates an inline area, a new LineLayoutManager object is created -(BlockLayoutManager.BlockLMiter.createLineManager). This +(BlockLayoutManager.ProxyLMiter.createLineManager). This LM asks the proxy to produce more child LMs. As long as these child LMs generate inline areas, they are collected by the LineLayoutManager object. Finally, the LineLayoutManager object creates its LMiter object as the -ListIterator over the list of collected child LMs. +ListIterator over the list of collected child +LMs.
@@ -265,7 +246,7 @@ same, but their childLMIter are different: [3] org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss (BlockLayoutManager.java:229) [4] org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss (FlowLayoutManager.java:111) [5] org.apache.fop.layoutmgr.PageLayoutManager.getNextBreakPoss (PageLayoutManager.java:261) - [6] org.apache.fop.layoutmgr.PageLayoutManager.doLayout (PageLayoutManager.java:228) + [6] org.apache.fop.layoutmgr.PageLayoutManager.activateLayout (PageLayoutManager.java:228) A TextLayoutManager: -- 2.39.5