Re: svn commit: r652673 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/events/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ src/java/org/apache/fop/layoutmgr/ test/fotree/testcas
On May 2, 2008, at 18:47, Adrian Cumiskey wrote: I'm guessing by "flaws and dirt" you are referring to the broken junit test in FOTreeTestSuite due to fo:retrieve-table-marker being a child of fo:block in test/fotree/testcases/table_retrieve-table- marker.fo. Indeed. The reason is I forgot to commit a small change to FObj to recognize the retrieve-table-marker as a 'neutral' item. Other flaws include the use of marker-class-name, where the actual property is retrieve-class-name... :/ Anyway, should be corrected after r652821. Spec states: "An fo:retrieve-table-marker is only permitted as the descendant of an fo:table-header or fo:table-footer or as a child of fo:table in a position where fo:table-header or fo:table-footer is permitted." Currently, only the latter part is not yet implemented. The implementation will cause an error if you use a fo:retrieve-table- marker outside of fo:table-header or fo:table-footer. It seems FOP is enforcing this. Would be good if you could fix this as I am ready to commit some of my own work to trunk but ideally would like to have a clean junit run before doing so. Should be possible now. Cheers Andreas
Re: svn commit: r652673 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/events/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ src/java/org/apache/fop/layoutmgr/ test/fotree/testcas
Hi Andreas, I'm guessing by "flaws and dirt" you are referring to the broken junit test in FOTreeTestSuite due to fo:retrieve-table-marker being a child of fo:block in test/fotree/testcases/table_retrieve-table-marker.fo. Spec states: "An fo:retrieve-table-marker is only permitted as the descendant of an fo:table-header or fo:table-footer or as a child of fo:table in a position where fo:table-header or fo:table-footer is permitted." It seems FOP is enforcing this. Would be good if you could fix this as I am ready to commit some of my own work to trunk but ideally would like to have a clean junit run before doing so. Adrian. Andreas Delmelle wrote: On May 1, 2008, at 23:34, [EMAIL PROTECTED] wrote: Author: adelmelle Date: Thu May 1 14:34:19 2008 New Revision: 652673 URL: http://svn.apache.org/viewvc?rev=652673&view=rev Log: First steps towards fo:retrieve-table-marker FWIW: I decided to finally look into this, as I've been noticing increasing demands for a port of 0.20.5's table-continuation extension. I already noticed some flaws and dirt in what I committed earlier; cleanup to follow as soon as SVN commit is restored. After this commit, the node is completely implemented on the fo-tree side, but still lacks a backing implementation in the layout engine. It does not yet generate any LayoutManagers (see modification to LayoutManagerMapping.java) In theory, everything is in place for the RetrieveTableMarker to behave in exactly the same way as a RetrieveMarker. Currently, a RetrieveMarker is intercepted and resolved in AbstractLayoutManager.createChildLMs(). I'm not sure yet if this suffices for a RetrieveTableMarker. Probably not... Resolution for regular RetrieveMarkers is ultimately triggered by StaticContentLM.getNextKnuthElements(), which in turn is called when finishing a page. At that point, the areas for the region-body's content will all have been added to the page, together with any associated fo:markers. It seems that, at least for retrieve-position-within-table="page", communication/interaction with the PageBreaker/PageSequenceLM is necessary. Any thoughts? Cheers Andreas
Re: svn commit: r652673 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/events/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ src/java/org/apache/fop/layoutmgr/ test/fotree/testcas
On May 1, 2008, at 23:34, [EMAIL PROTECTED] wrote: Author: adelmelle Date: Thu May 1 14:34:19 2008 New Revision: 652673 URL: http://svn.apache.org/viewvc?rev=652673&view=rev Log: First steps towards fo:retrieve-table-marker FWIW: I decided to finally look into this, as I've been noticing increasing demands for a port of 0.20.5's table-continuation extension. I already noticed some flaws and dirt in what I committed earlier; cleanup to follow as soon as SVN commit is restored. After this commit, the node is completely implemented on the fo-tree side, but still lacks a backing implementation in the layout engine. It does not yet generate any LayoutManagers (see modification to LayoutManagerMapping.java) In theory, everything is in place for the RetrieveTableMarker to behave in exactly the same way as a RetrieveMarker. Currently, a RetrieveMarker is intercepted and resolved in AbstractLayoutManager.createChildLMs(). I'm not sure yet if this suffices for a RetrieveTableMarker. Probably not... Resolution for regular RetrieveMarkers is ultimately triggered by StaticContentLM.getNextKnuthElements(), which in turn is called when finishing a page. At that point, the areas for the region-body's content will all have been added to the page, together with any associated fo:markers. It seems that, at least for retrieve-position-within-table="page", communication/interaction with the PageBreaker/PageSequenceLM is necessary. Any thoughts? Cheers Andreas
