RE: import statements (RE: StaticContentLayoutManager)
Glen Mazza wrote: On another issue, Victor, *please* don't forget to fully qualify the import statements -- that's one of our coding conventions and very helpful in grokking code -- a import org.apache.fop.apps.*; was added last week in the PDFRenderer.java: Well, it isn't a matter of forgetting. I know all about it, and there are lots more than the one you point out. My IDE is doing this when it does its nice move and rename refactorings. It is even adding them in classes where they are not needed. I have also introduced many other checkstyle problems along the way, mostly missing javadoc comments for new accessor methods, etc. I'll fix them in batch mode when I can come up for air. If all of our checkstyle problems were fixed, it would be easy to just run the report before doing a commit and fix any that showed up. But there is no practical way to do this with hundreds still out there. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/rtf/renderer RTFHandler.java
gmazza 2003/08/31 18:28:51
Modified:src/java/org/apache/fop/area CachedRenderPagesModel.java
src/java/org/apache/fop/datatypes ColorType.java
src/java/org/apache/fop/fo PropertyManager.java
src/java/org/apache/fop/render AbstractRenderer.java
src/java/org/apache/fop/render/awt AWTRenderer.java
src/java/org/apache/fop/render/pdf PDFRenderer.java
src/java/org/apache/fop/render/ps PSRenderer.java
src/java/org/apache/fop/rtf/renderer RTFHandler.java
Log:
1. Partial implementation of fo:region-xxx and background-color property
in AWTRenderer.
2. ColorType has a new getAWTColor() method, also alpha() function renamed
to getAlpha(). Definition of Alpha values switched to make consistent with
java.awt.Color (i.e., 0 is transparent and 1 is opaque).
3. AbstractRenderer's handleViewportTraits() renamed to handleRegionTraits()
to lesson confusion (FOP has three types of viewports--
Page, Region, and Block--handleViewportTraits() was only good for Region.)
Revision ChangesPath
1.2 +1 -1 xml-fop/src/java/org/apache/fop/area/CachedRenderPagesModel.java
Index: CachedRenderPagesModel.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/area/CachedRenderPagesModel.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CachedRenderPagesModel.java 11 Mar 2003 13:05:27 - 1.1
+++ CachedRenderPagesModel.java 1 Sep 2003 01:28:51 - 1.2
@@ -68,7 +68,7 @@
* A simple cached render pages model.
* If the page is prepared for later rendering then this saves
* the page contents to a file and once the page is resolved
- * the contents a reloaded.
+ * the contents are reloaded.
*/
public class CachedRenderPagesModel extends RenderPagesModel {
private Map pageMap = new HashMap();
1.3 +20 -9 xml-fop/src/java/org/apache/fop/datatypes/ColorType.java
Index: ColorType.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datatypes/ColorType.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ColorType.java5 Jul 2003 03:23:23 - 1.2
+++ ColorType.java1 Sep 2003 01:28:51 - 1.3
@@ -50,6 +50,7 @@
*/
package org.apache.fop.datatypes;
+import java.awt.Color;
import java.io.Serializable;
import java.util.StringTokenizer;
@@ -61,22 +62,24 @@
/**
* the red component
*/
-protected float red;
+protected float red = 0f;
/**
* the green component
*/
-protected float green;
+protected float green = 0f;
/**
* the blue component
*/
-protected float blue;
+protected float blue = 0f;
/**
- * the alpha component
+ * the alpha component (indicator of opaque-ness)
+ * 0.0 - 1.0; 0.0 is completely transparent; 1.0 is completely opaque
+ * see definition at http://java.sun.com/j2se/1.3/docs/api/java/awt/Color.html
*/
-protected float alpha = 0;
+protected float alpha = 1f;
/**
* Main constructor
@@ -177,7 +180,7 @@
this.red = 0;
this.green = 0;
this.blue = 0;
-this.alpha = 1;
+this.alpha = 0;
} else {
boolean found = false;
for (int count = 0; count NAMES.length; count++) {
@@ -225,11 +228,19 @@
}
/**
- * Returns the alpha (transparency) component of the color.
- * @return float a value between 0.0 and 1.0
+ * Returns the alpha (degree of opaque-ness) component of the color.
+ * @return float a value between 0.0 (fully transparent) and 1.0 (fully opaque)
*/
-public float alpha() {
+public float getAlpha() {
return this.alpha;
+}
+
+/**
+ * Returns an AWT instance of this color
+ * @return float the AWT color represented by this ColorType instance
+ */
+public Color getAWTColor() {
+return new Color(this.red, this.green, this.blue, this.alpha);
}
/**
1.12 +1 -1 xml-fop/src/java/org/apache/fop/fo/PropertyManager.java
Index: PropertyManager.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/PropertyManager.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- PropertyManager.java 24 Aug 2003 17:46:10 - 1.11
+++ PropertyManager.java 1 Sep 2003 01:28:51 - 1.12
@@ -337,7 +337,7 @@
fo isolation complete (almost)
FOP Developers: The FO Tree isolation work is complete, with the exception of a few classes that I would like to move around, and for which I would welcome input. I started this for the purpose of making sure that layout and FO Tree were isolated, but I actually ended up isolating FO Tree from everything else. I think this not only has benefits in helping us keep our code modularized, but also has potential to make the FO Tree be useful to other projects as a separate stand-alone product. In other words, we could think of FO Tree as a separate project that is a service to FOP and to anyone else who might benefit from such a data structure. As I proceeded with this work, it seemed to me that there are a total of five such modules within FOP. The table below summarizes these modules, with column 1 representing the FO Tree, column 2 the area tree, column 3a the renderers, column 3b the layout, and column 4 the FOP application itself. Of these five isolation groups, only column 1 is realized currently. Package1 2 3a 3b 4 -|---|---|---|---|---| apps | | | | | x | area | | x | | | | datatypes| x | | | | | fo | x | | | | | fonts| x | | | | | image| x | | | | | layout | | | | x | | layoutmgr| | | | x | | mif | | | x | | | pdf | | | x | | | render | | | x | | | rtf | | | x | | | servlet | | | | | x | svg | | | x | | | tools| | | x | | | traits | x | | | | | util | x | | | | | viewer | | | x | | | -|---|---|---|---|---| common? | x | | | | | Columns 3a and 3b are at the same level because they could be done in either order, and need to maintain isolation between themselves. So, in other words, FO Tree should be built in isolation from everything else. Area tree is built in isolation from everything except FO Tree. Renderers are built in isolation from everything except FO Tree and Area Tree. Layout is built in isolation from everything except FO Tree and Area Tree. Finally, the apps pull all of it together. Note 1: layout has further issues in that each layout strategy should be built independently of all others, but of course with visibility of any code that is designated as common to all of them. Note 2: One could break column 1 into two columns, one for common code and one for actual FO Tree building, but I don't see a great benefit to doing so. Now, I would like to change our build process to enforce the above dependencies as they are realized. In other words, I would like to use our build to help us make sure that we don't have code creeping between the modules. Consider the five modules: apps uses everything, so all it needs to do is build last. FO Tree and Area Tree are essentially data structures, with methods to build and manage those structures. That leaves Layout and Rendering, *both* of which now we are trying to make pluggable, and which can and should be totally separate from each other. So I propose first that keeping these five modules separate is a desirable thing, and should be enforced by our build process (I'll write the code). Here is my +1. Now in the table above, the common package does not exist, but represents five classes that I would like to move to complete the process of isolating column 1. Those classes are: apps/FOPException apps/FOUserAgent apps/FOFileHandler apps/InputHandler pdf/PDFEncryptionParams apps/FOFileHandler and apps/InputHandler could logically go into the FO Tree package. The remaining items (or all of them) could go into util. They basically represent things that are common to all FOP modules. I also thought about creating a new exception class just for FO Tree building, which would solve the isolation problem for column 1, but not for any other modules. apps/FOUserAgent and pdf/PDFEncryptionParams are essentially configuration classes. Does anyone care where I put them or object to me moving them? If we come to general agreement that subdiving FOP this way is good, I'll complete implementation of it before trying to bring the old layout over (which I am really itching to get started on). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: fo isolation complete (almost)
Victor Mote wrote: If we come to general agreement that subdiving FOP this way is good, I'll ^ Sorry, this word should be subdividing. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs compliance.xml
vmote 2003/09/01 05:15:52 Modified:src/documentation/content/xdocs compliance.xml Log: add comments about current implementation of block-container object, submitted by Chris Bowditch [EMAIL PROTECTED]; see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22811 Revision ChangesPath 1.22 +4 -1 xml-fop/src/documentation/content/xdocs/compliance.xml Index: compliance.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/compliance.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- compliance.xml26 Aug 2003 21:56:28 - 1.21 +++ compliance.xml1 Sep 2003 12:15:52 - 1.22 @@ -45,7 +45,10 @@ /level-2 level-2 name=Block Formatting Objects citation=§6.5 extURL=slice6.html#section-N12764-Block-level-Formatting-Objects ref-name=block level-3 name=block citation=§6.5.2 extURL=slice6.html#fo_block compliance-level=1 comply=yes/ - level-3 name=block-container citation=§6.5.3 extURL=slice6.html#fo_block-container compliance-level=2 comply=partial/ + level-3 name=block-container citation=§6.5.3 extURL=slice6.html#fo_block-container compliance-level=2 comply=partial +commentCurrently only works as direct child of fo:flow./comment +commentFor absolute positioning, use 'position=absolute' (as 'absolute-position=absolute' is not implemented), and specify all four of left, top, width and height/comment + /level-3 /level-2 level-2 name=Inline Formatting Objects citation=§6.6 extURL=slice6.html#section-N13277-Inline-level-Formatting-Objects ref-name=inline level-3 name=bidi-override citation=§6.6.2 extURL=slice6.html#fo_bidi-override compliance-level=2 comply=no/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22811] - [PATCH] block-container notes on compliance page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22811. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22811 [PATCH] block-container notes on compliance page [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 12:22 --- I have just committed a change for this patch (after some minor editing). Thanks very much Chris. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/apps CommandLineOptions.java Document.java FOPException.java FOUserAgent.java InputHandler.java
vmote 2003/09/01 06:31:24
Modified:src/java/org/apache/fop/apps CommandLineOptions.java
Document.java FOPException.java FOUserAgent.java
InputHandler.java
Log:
style/javadoc changes only
Revision ChangesPath
1.13 +13 -13xml-fop/src/java/org/apache/fop/apps/CommandLineOptions.java
Index: CommandLineOptions.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CommandLineOptions.java 12 Aug 2003 22:40:49 - 1.12
+++ CommandLineOptions.java 1 Sep 2003 13:31:24 - 1.13
@@ -64,31 +64,31 @@
*/
public class CommandLineOptions {
-/* input / output not set */
+/** input / output not set */
public static final int NOT_SET = 0;
-/* input: fo file */
+/** input: fo file */
public static final int FO_INPUT = 1;
-/* input: xml+xsl file */
+/** input: xml+xsl file */
public static final int XSLT_INPUT = 2;
-/* output: pdf file */
+/** output: pdf file */
public static final int PDF_OUTPUT = 1;
-/* output: screen using swing */
+/** output: screen using swing */
public static final int AWT_OUTPUT = 2;
-/* output: mif file */
+/** output: mif file */
public static final int MIF_OUTPUT = 3;
-/* output: sent swing rendered file to printer */
+/** output: sent swing rendered file to printer */
public static final int PRINT_OUTPUT = 4;
-/* output: pcl file */
+/** output: pcl file */
public static final int PCL_OUTPUT = 5;
-/* output: postscript file */
+/** output: postscript file */
public static final int PS_OUTPUT = 6;
-/* output: text file */
+/** output: text file */
public static final int TXT_OUTPUT = 7;
-/* output: svg file */
+/** output: svg file */
public static final int SVG_OUTPUT = 8;
-/* output: XML area tree */
+/** output: XML area tree */
public static final int AREA_OUTPUT = 9;
-/* output: RTF file */
+/** output: RTF file */
public static final int RTF_OUTPUT = 10;
/* show configuration information */
1.5 +12 -4 xml-fop/src/java/org/apache/fop/apps/Document.java
Index: Document.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/Document.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Document.java 26 Aug 2003 19:28:46 - 1.4
+++ Document.java 1 Sep 2003 13:31:24 - 1.5
@@ -95,10 +95,9 @@
*/
private LayoutStrategy layoutStrategy = null;
-/**
- * The current AreaTree for the PageSequence being rendered.
- */
+/** The current AreaTree for the PageSequence being rendered. */
public AreaTree areaTree;
+/** The AreaTreeModel for the PageSequence being rendered. */
public AreaTreeModel atModel;
private Bookmarks bookmarks = null;
@@ -350,10 +349,19 @@
return areaTree;
}
+/**
+ * Set the Bookmarks object for this Document
+ * @param bookmarks the Bookmarks object containing the bookmarks for this
+ * Document
+ */
public void setBookmarks(Bookmarks bookmarks) {
this.bookmarks = bookmarks;
}
+/**
+ * Public accessor for the Bookmarks for this Document
+ * @return the Bookmarks for this Document
+ */
public Bookmarks getBookmarks() {
return bookmarks;
}
1.3 +4 -0 xml-fop/src/java/org/apache/fop/apps/FOPException.java
Index: FOPException.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/FOPException.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FOPException.java 5 Jul 2003 09:28:34 - 1.2
+++ FOPException.java 1 Sep 2003 13:31:24 - 1.3
@@ -105,6 +105,10 @@
return exception;
}
+/**
+ * Attempts to recast the exception as other Throwable types.
+ * @return the exception recast as another type if possible, otherwise null.
+ */
protected Throwable getRootException() {
Throwable result = exception;
1.4 +3 -1 xml-fop/src/java/org/apache/fop/apps/FOUserAgent.java
Index: FOUserAgent.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/FOUserAgent.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
---
cvs commit: xml-fop/src/java/org/apache/fop/fo ToBeImplementedElement.java Unknown.java UnknownXMLObj.java XMLElement.java XMLObj.java
vmote 2003/09/01 06:42:35
Modified:src/java/org/apache/fop/fo ToBeImplementedElement.java
Unknown.java UnknownXMLObj.java XMLElement.java
XMLObj.java
Log:
style/javadoc changes only
Revision ChangesPath
1.4 +6 -0 xml-fop/src/java/org/apache/fop/fo/ToBeImplementedElement.java
Index: ToBeImplementedElement.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/ToBeImplementedElement.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ToBeImplementedElement.java 19 Aug 2003 00:53:52 - 1.3
+++ ToBeImplementedElement.java 1 Sep 2003 13:42:35 - 1.4
@@ -67,6 +67,12 @@
+ \ is not yet implemented.);
}
+/**
+ * This is a hook for an FOTreeVisitor subclass to be able to access
+ * this object.
+ * @param fotv the FOTreeVisitor subclass that can access this object.
+ * @see org.apache.fop.fo.FOTreeVisitor
+ */
public void acceptVisitor(FOTreeVisitor fotv) {
fotv.serveVisitor(this);
}
1.4 +6 -0 xml-fop/src/java/org/apache/fop/fo/Unknown.java
Index: Unknown.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/Unknown.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Unknown.java 19 Aug 2003 00:53:53 - 1.3
+++ Unknown.java 1 Sep 2003 13:42:35 - 1.4
@@ -84,6 +84,12 @@
getLogger().debug(Layout Unknown element);
}
+/**
+ * This is a hook for an FOTreeVisitor subclass to be able to access
+ * this object.
+ * @param fotv the FOTreeVisitor subclass that can access this object.
+ * @see org.apache.fop.fo.FOTreeVisitor
+ */
public void acceptVisitor(FOTreeVisitor fotv) {
fotv.serveVisitor(this);
}
1.4 +6 -0 xml-fop/src/java/org/apache/fop/fo/UnknownXMLObj.java
Index: UnknownXMLObj.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/UnknownXMLObj.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- UnknownXMLObj.java19 Aug 2003 00:53:53 - 1.3
+++ UnknownXMLObj.java1 Sep 2003 13:42:35 - 1.4
@@ -118,6 +118,12 @@
super.addCharacters(data, start, length);
}
+/**
+ * This is a hook for an FOTreeVisitor subclass to be able to access
+ * this object.
+ * @param fotv the FOTreeVisitor subclass that can access this object.
+ * @see org.apache.fop.fo.FOTreeVisitor
+ */
public void acceptVisitor(FOTreeVisitor fotv) {
fotv.serveVisitor(this);
}
1.3 +6 -0 xml-fop/src/java/org/apache/fop/fo/XMLElement.java
Index: XMLElement.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/XMLElement.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- XMLElement.java 19 Aug 2003 00:53:53 - 1.2
+++ XMLElement.java 1 Sep 2003 13:42:35 - 1.3
@@ -86,6 +86,12 @@
return namespace;
}
+/**
+ * This is a hook for an FOTreeVisitor subclass to be able to access
+ * this object.
+ * @param fotv the FOTreeVisitor subclass that can access this object.
+ * @see org.apache.fop.fo.FOTreeVisitor
+ */
public void acceptVisitor(FOTreeVisitor fotv) {
fotv.serveVisitor(this);
}
1.5 +6 -0 xml-fop/src/java/org/apache/fop/fo/XMLObj.java
Index: XMLObj.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/XMLObj.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- XMLObj.java 19 Aug 2003 00:53:53 - 1.4
+++ XMLObj.java 1 Sep 2003 13:42:35 - 1.5
@@ -231,6 +231,12 @@
element.appendChild(text);
}
+/**
+ * This is a hook for an FOTreeVisitor subclass to be able to access
+ * this object.
+ * @param fotv the FOTreeVisitor subclass that can access this object.
+ * @see org.apache.fop.fo.FOTreeVisitor
+ */
public void acceptVisitor(FOTreeVisitor fotv) {
fotv.serveVisitor(this);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageLayoutManager.java
vmote 2003/09/01 07:11:51
Modified:src/java/org/apache/fop/layoutmgr PageLayoutManager.java
Log:
1. reduce visibility of many classes
2. some style/javadoc changes
Revision ChangesPath
1.19 +11 -15xml-fop/src/java/org/apache/fop/layoutmgr/PageLayoutManager.java
Index: PageLayoutManager.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/PageLayoutManager.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- PageLayoutManager.java29 Aug 2003 20:02:11 - 1.18
+++ PageLayoutManager.java1 Sep 2003 14:11:51 - 1.19
@@ -92,7 +92,7 @@
import java.awt.Rectangle;
import java.util.Iterator;
import java.awt.geom.Rectangle2D;
-import org.apache.fop.traits.*;
+import org.apache.fop.traits.MinOptMax;
/**
* LayoutManager for a PageSequence and its flow.
@@ -610,7 +610,7 @@
*
* @param breakVal the break value to handle
*/
-protected void handleBreak(int breakVal) {
+private void handleBreak(int breakVal) {
if (breakVal == Constants.COLUMN) {
if (curSpan != null
curSpan.getColumnCount() != curSpanColumns) {
@@ -727,7 +727,7 @@
* @return the page viewport created for the page number
* @throws FOPException if there is an error creating page
*/
-public PageViewport createPage(boolean bIsBlank, boolean bIsLast)
+private PageViewport createPage(boolean bIsBlank, boolean bIsLast)
throws FOPException {
currentSimplePageMaster = getSimplePageMasterToUse(bIsBlank);
Region body = currentSimplePageMaster.getRegion(Region.BODY);
@@ -760,7 +760,7 @@
.getNextSimplePageMaster(isOddPage, isFirstPage, bIsBlank);
}
-public PageViewport createPageAreas(SimplePageMaster spm) {
+private PageViewport createPageAreas(SimplePageMaster spm) {
int pageWidth =
spm.properties.get(page-width).getLength().getValue();
int pageHeight =
@@ -819,8 +819,8 @@
* @param pageCTM page coordinate transformation matrix
* @return the new region viewport
*/
-public RegionViewport makeRegionViewport(Region r, FODimension reldims, CTM
pageCTM) {
-Rectangle2D relRegionRect = r. getViewportRectangle(reldims);
+private RegionViewport makeRegionViewport(Region r, FODimension reldims, CTM
pageCTM) {
+Rectangle2D relRegionRect = r.getViewportRectangle(reldims);
Rectangle2D absRegionRect = pageCTM.transform(relRegionRect);
// Get the region viewport rectangle in absolute coords by
// transforming it using the page CTM
@@ -836,7 +836,7 @@
*
* @param r the region viewport
*/
-protected void setRegionViewportTraits(Region r, RegionViewport rv) {
+private void setRegionViewportTraits(Region r, RegionViewport rv) {
// Common Border, Padding, and Background Properties
CommonBorderAndPadding bap = r.getPropertyManager().getBorderAndPadding();
CommonBackground bProps = r.getPropertyManager().getBackgroundProps();
@@ -844,11 +844,7 @@
TraitSetter.addBackground(rv, bProps);
}
-/**
- * Override the inherited method.
- * @see org.apache.fop.fo.pagination.Region#makeRegionReferenceArea(Rectangle2D)
- */
-public RegionReference makeRegionBodyReferenceArea(Region r,
+private RegionReference makeRegionBodyReferenceArea(Region r,
Rectangle2D absRegVPRect) {
// Should set some column stuff here I think, or put it elsewhere
BodyRegion body = new BodyRegion();
@@ -877,7 +873,7 @@
* height=top-bottom
* @return a new region reference area
*/
-public RegionReference makeRegionReferenceArea(Region r,
+private RegionReference makeRegionReferenceArea(Region r,
Rectangle2D absRegVPRect) {
RegionReference rr = new RegionReference(r.getRegionClassCode());
setRegionPosition(r, rr, absRegVPRect);
@@ -892,7 +888,7 @@
* @param r the region reference area
* @param absRegVPRect the rectangle to place the region contents
*/
-public void setRegionPosition(Region r, RegionReference rr,
+private void setRegionPosition(Region r, RegionReference rr,
Rectangle2D absRegVPRect) {
FODimension reldims = new FODimension(0, 0);
rr.setCTM(CTM.getCTMandRelDims(r.getPropertyManager().getAbsRefOrient(),
@@ -902,7 +898,7 @@
/**
* @return a StaticContent layout manager
*/
-public StaticContentLayoutManager getStaticContentLayoutManager(StaticContent
sc) {
+private
cvs commit: xml-fop/src/java/org/apache/fop/render/ps PSRenderer.java
vmote 2003/09/01 07:19:35
Modified:src/java/org/apache/fop/render AbstractRenderer.java
src/java/org/apache/fop/render/awt AWTRenderer.java
src/java/org/apache/fop/render/pdf PDFRenderer.java
src/java/org/apache/fop/render/ps PSRenderer.java
Log:
clean up some gump javadoc warnings
Revision ChangesPath
1.12 +2 -2 xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java
Index: AbstractRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- AbstractRenderer.java 1 Sep 2003 01:28:51 - 1.11
+++ AbstractRenderer.java 1 Sep 2003 14:19:34 - 1.12
@@ -330,8 +330,8 @@
/**
* Handle the traits for a region
- * This is used to draw the traits for the given page region
- * (see Sect. 6.4.1.2 of XSL-FO spec.)
+ * This is used to draw the traits for the given page region.
+ * (See Sect. 6.4.1.2 of XSL-FO spec.)
* @param rv the RegionViewport whose region is to be drawn
*/
protected void handleRegionTraits(RegionViewport rv) {
1.11 +17 -17xml-fop/src/java/org/apache/fop/render/awt/AWTRenderer.java
Index: AWTRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/awt/AWTRenderer.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- AWTRenderer.java 1 Sep 2003 01:28:51 - 1.10
+++ AWTRenderer.java 1 Sep 2003 14:19:34 - 1.11
@@ -106,7 +106,7 @@
protected double scaleFactor = 100.0;
protected int pageNumber = 0;
protected Vector pageViewportList = new java.util.Vector();
-protected Vector pageList = new java.util.Vector();
+protected Vector pageList = new java.util.Vector();
protected BufferedImage currentPageImage = null;
/** Font configuration */
@@ -243,15 +243,15 @@
frame.setStatus(translator.getString(Status.Build.FO.tree));
return frame;
}
-
+
/** This method override only stores the PageViewport in a vector.
* No actual rendering performed -- this is done by getPageImage(pageNum)
instead.
* @param pageViewport the codePageViewport/code object supplied by the
Area Tree
- * @see org.apache.fop.render.Renderer
+ * @see org.apache.fop.render.Renderer
*/
public void renderPage(PageViewport pageViewport) throws IOException,
FOPException {
pageViewportList.add(pageViewport);
-pageList.add(pageViewport.getPage().clone());
+pageList.add(pageViewport.getPage().clone());
}
/** Generates a desired page from the renderer's page viewport vector.
@@ -261,13 +261,13 @@
*/
public BufferedImage getPageImage(int pageNum) throws FOPException {
if (pageNum 0 || pageNum = pageViewportList.size()) {
-throw new FOPException(out-of-range page number ( + pageNum
-+ ) requested; only + pageViewportList.size()
+throw new FOPException(out-of-range page number ( + pageNum
++ ) requested; only + pageViewportList.size()
+ page(s) available.);
}
PageViewport pageViewport = (PageViewport) pageViewportList.get(pageNum);
Page page = (Page) pageList.get(pageNum);
-
+
Rectangle2D bounds = pageViewport.getViewArea();
int pageWidth = (int)((float) bounds.getWidth() / 1000f + .5);
int pageHeight = (int)((float) bounds.getHeight() / 1000f + .5);
@@ -276,7 +276,7 @@
+ + bounds.getY()
+ + bounds.getWidth()
+ + bounds.getHeight());
-*/
+*/
currentPageImage =
new BufferedImage((int)((pageWidth * (int)scaleFactor) / 100),
(int)((pageHeight * (int)scaleFactor) / 100),
@@ -290,7 +290,7 @@
AffineTransform at = graphics.getTransform();
at.scale(scaleFactor / 100.0, scaleFactor / 100.0);
graphics.setTransform(at);
-
+
// draw page frame
graphics.setColor(Color.white);
graphics.fillRect(0, 0, pageWidth, pageHeight);
@@ -309,8 +309,8 @@
/**
* Handle the traits for a region
- * This is used to draw the traits for the given page region
- * (see Sect. 6.4.1.2 of XSL-FO spec.)
+ * This is used to draw the traits for the given page region.
+ * (See Sect. 6.4.1.2 of XSL-FO spec.)
* @param region the RegionViewport whose region is to be drawn
*/
protected void
Re: fo isolation complete (almost)
--- Victor Mote [EMAIL PROTECTED] wrote: So I propose first that keeping these five modules separate is a desirable thing, and should be enforced by our build process (I'll write the code). Here is my +1. I'm -1. The decision for changing FOP architecture is based on votes--not just by current but future committers, who may have other architectural ideas that don't include FOTree isolation. Enforcing architectural designs via the build process could be hindering future design issues from presenting themselves and being voted on. There are two major architectural paths for FOP--one is based on the pipeline approach (apps package just activates the FO processing which interfaces with Area Tree processing, etc., etc., with business logic split among the five areas), which I tended to favor, and the other is the controlling-class approach (have apps run the show, and render the other areas as primarily services to it), largely supported by you and the other committers. On the basis of all your work over the past several weeks in cleaning up the code, as well as the fact that the other committers either have little problem with or actually support the controlling-class approach, I have no problem with us going in this direction right now. I don't want to freeze out, however, a future pipelined approach should inordinate problems present themselves with this design. (Besides, my AWTRenderer is reentrant, and depends on a locally created Driver instance to reload its document! ;) Now in the table above, the common package does not exist, but represents five classes that I would like to move to complete the process of isolating column 1. Those classes are: apps/FOPException apps/FOUserAgent apps/FOFileHandler apps/InputHandler pdf/PDFEncryptionParams Arguably, you would need to add Version and XSLTInputHandler as well to this. But we have a more pressing concern with backwards compatibility (with FOPException and the embedded InputHandlers) and also user (embedded) code cleanliness--when users embed FOP in their code, I would rather they only access one of our packages (namely org.apache.fop.apps), rather than multiple packages--that wouldn't look like a good design decision on our part. fop.PDF.* I would like to have moved under the render.pdf package as a new subpackage--because everything within it is specific to PDF rendering, and none of the other renderers. Also, I would like to move the fop.viewer package to render.awt.viewer as well--again, it is only specific to AWT Rendering. FOUserAgent's location I don't care about. If we come to general agreement that subdiving FOP this way is good, I'll complete implementation of it before trying to bring the old layout over (which I am really itching to get started on). Too early to tell, I think. You have 90% isolation, I think that's good enough right now--perhaps working on the old layout would be best at this time. Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo isolation complete (almost)
Victor Mote wrote: [interesting stuff] Package1 2 3a 3b 4 tools| | | x | | | Should be 4 (apps) module, I think. util | x | | | | | Uh, I never liked that. Here is my +1. +0 Now in the table above, the common package does not exist, but represents five classes that I would like to move to complete the process of isolating column 1. Those classes are: apps/FOPException +1 apps/FOUserAgent ??? apps/FOFileHandler apps/InputHandler Should stay in apps pdf/PDFEncryptionParams Why should this go into a commons? apps/FOFileHandler and apps/InputHandler could logically go into the FO Tree package. I don't think so. They are abstractions for the Processor input and don't have anything to do with the FO tree. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: fo isolation complete (almost)
Glen Mazza wrote: --- Victor Mote [EMAIL PROTECTED] wrote: So I propose first that keeping these five modules separate is a desirable thing, and should be enforced by our build process (I'll write the code). Here is my +1. I'm -1. The decision for changing FOP architecture is based on votes--not just by current but future committers, who may have other architectural ideas that don't include FOTree isolation. Enforcing architectural designs via the build process could be hindering future design issues from presenting themselves and being voted on. Nothing I am proposing here should be construed to prevent future committers from changing this if they wish to. They can change the build process just as easily as we can. The point of having the build process enforce this is to at least make someone stop and think about it before doing so. Before starting down this path, I tried pretty hard to think of a use case where it is beneficial *not* to have the FO Tree isolated, and could not think of one. If you know of one, it will help a lot for you to mention it. It was a fair chunk of work to get it isolated, and I would like to make sure that it stays isolated unless there is a really good reason for it. There are two major architectural paths for FOP--one is based on the pipeline approach (apps package just activates the FO processing which interfaces with Area Tree processing, etc., etc., with business logic split among the five areas), which I tended to favor, and the other is the controlling-class approach (have apps run the show, and render the other areas as primarily services to it), largely supported by you and the other committers. I guess I don't see these as being so different, nor the distinction between them as the main issue. Even in a pipeline approach, the pipeline itself is defined somewhere. If we use Cocoon as an example (I am no expert, but think I grasp the concepts), the Cocoon script is the glue that binds the services together into a cohesive, useful pipeline. I view apps as being the place where that pipeline is defined. I frankly see a clear delineation of the tasks (i.e. getting keeping the modules separate) as being a prerequisite for either approach, so I am more than a little confused by your objection. The main issue is whether we are modular or not. With two data structures and two processing concepts (both of which benefit from being pluggable), modularity (and distinction between modules) seems to me to be a high priority, around which we should work almost everything. Pressing the Cocoon analogy a bit further, if you had an XSLT processor that automatically fired up FOP each time it ran, it wouldn't be useful for anything other than running FOP. You couldn't use it, for example, to spit out HTML. So the fact that the XSLT processor is completely distinct from FOP (i.e. isolated) is a Good Thing. The build processes of the two keep them distinct, as it should be. Getting them mixed together would actually hinder the usefulness of the pipeline approach. On the basis of all your work over the past several weeks in cleaning up the code, as well as the fact that the other committers either have little problem with or actually support the controlling-class approach, I have no problem with us going in this direction right now. I don't want to freeze out, however, a future pipelined approach should inordinate problems present themselves with this design. (Besides, my AWTRenderer is reentrant, and depends on a locally created Driver instance to reload its document! ;) I'd be glad to help you think through how this could work differently. I still have a lot of cleaning up to do between Driver and Document, and I'll bet that anything you are trying to do can be handled properly when we get those classes cleaned up. Now in the table above, the common package does not exist, but represents five classes that I would like to move to complete the process of isolating column 1. Those classes are: apps/FOPException apps/FOUserAgent apps/FOFileHandler apps/InputHandler pdf/PDFEncryptionParams Arguably, you would need to add Version and XSLTInputHandler as well to this. But we have a more pressing concern with backwards compatibility (with FOPException and the embedded InputHandlers) and also user (embedded) code cleanliness--when users embed FOP in their code, I would rather they only access one of our packages (namely org.apache.fop.apps), rather than multiple packages--that wouldn't look like a good design decision on our part. Those are good points. I guess I don't understand why anyone would need access to the InputHandlers? WRT FOPException, I can handle that by creating a new Exception class just for FO Tree, but then would have to do so for each of the other modules as well. That may be a good thing. I'll have to think about that some more. fop.PDF.* I would like to have moved under the
RE: fo isolation complete (almost)
J.Pietschmann wrote: Victor Mote wrote: [interesting stuff] Package1 2 3a 3b 4 tools| | | x | | | Should be 4 (apps) module, I think. util | x | | | | | Uh, I never liked that. Here is my +1. +0 Now in the table above, the common package does not exist, but represents five classes that I would like to move to complete the process of isolating column 1. Those classes are: apps/FOPException +1 apps/FOUserAgent ??? AFAIK, this is really configuration options. apps/FOFileHandler apps/InputHandler Should stay in apps See below for discussion. pdf/PDFEncryptionParams Why should this go into a commons? I agree that commons isn't the right concept. This is really configuration stuff, which generally needs to be available to all of the modules. apps/FOFileHandler and apps/InputHandler could logically go into the FO Tree package. I don't think so. They are abstractions for the Processor input and don't have anything to do with the FO tree. My preference would really be to put them in a parse package. We have kind of lumped parsing in with FO Tree building as a practical matter, hence my comment. Since we have the Structure Renderers, we really have parsing without FO Tree building. One possibility would be to create an apps.common (or whatever) package to throw this stuff into. That way the build process could distinguish them, but would still be picked up in apps (this would solve Glen's concern about FOException as well). Conclusion: We have three active committers right now, one positive, one negative, one lukewarm, so I will abandon the enforcement idea. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fo FOInputHandler.java FOTreeControl.java FObj.java
vmote 2003/09/01 12:21:08
Modified:src/java/org/apache/fop/apps Document.java
src/java/org/apache/fop/fo FOInputHandler.java
FOTreeControl.java FObj.java
Log:
move storage of ID references from fo/FOInputHandler to fo/FOTreeControl
(implemented in apps/Document)
Revision ChangesPath
1.6 +18 -1 xml-fop/src/java/org/apache/fop/apps/Document.java
Index: Document.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/apps/Document.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Document.java 1 Sep 2003 13:31:24 - 1.5
+++ Document.java 1 Sep 2003 19:21:07 - 1.6
@@ -53,6 +53,9 @@
// Java
import java.util.Map;
import java.io.IOException;
+import java.util.Set;
+import java.util.HashSet;
+
// FOP
import org.apache.fop.area.AreaTree;
@@ -103,6 +106,12 @@
private Bookmarks bookmarks = null;
/**
+ * The current set of id's in the FO tree.
+ * This is used so we know if the FO tree contains duplicates.
+ */
+private Set idReferences = new HashSet();
+
+/**
* Main constructor
* @param driver the Driver object that is the parent of this Document
*/
@@ -364,6 +373,14 @@
*/
public Bookmarks getBookmarks() {
return bookmarks;
+}
+
+/**
+ * Retuns the set of ID references.
+ * @return the ID references
+ */
+public Set getIDReferences() {
+return idReferences;
}
}
1.8 +1 -19 xml-fop/src/java/org/apache/fop/fo/FOInputHandler.java
Index: FOInputHandler.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOInputHandler.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- FOInputHandler.java 21 Aug 2003 19:22:21 - 1.7
+++ FOInputHandler.java 1 Sep 2003 19:21:07 - 1.8
@@ -50,10 +50,6 @@
*/
package org.apache.fop.fo;
-// Java
-import java.util.Set;
-import java.util.HashSet;
-
// Avalon
import org.apache.avalon.framework.logger.AbstractLogEnabled;
@@ -87,12 +83,6 @@
*/
public abstract class FOInputHandler extends AbstractLogEnabled {
/**
- * The current set of id's in the FO tree.
- * This is used so we know if the FO tree contains duplicates.
- */
-private Set idReferences = new HashSet();
-
-/**
* The FOTreeControl object that is controlling the FO Tree being built
*/
public FOTreeControl foTreeControl = null;
@@ -104,14 +94,6 @@
*/
public FOInputHandler(FOTreeControl foTreeControl) {
this.foTreeControl = foTreeControl;
-}
-
-/**
- * Retuns the set of ID references.
- * @return the ID references
- */
-public Set getIDReferences() {
-return idReferences;
}
/**
1.6 +8 -1 xml-fop/src/java/org/apache/fop/fo/FOTreeControl.java
Index: FOTreeControl.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOTreeControl.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FOTreeControl.java1 Sep 2003 18:33:05 - 1.5
+++ FOTreeControl.java1 Sep 2003 19:21:07 - 1.6
@@ -53,6 +53,7 @@
// Java
import java.util.Map;
+import java.util.Set;
// FOP
import org.apache.fop.fo.extensions.Bookmarks;
@@ -106,5 +107,11 @@
* @return the Bookmark object encapsulating the bookmarks for the FO Tree.
*/
Bookmarks getBookmarks();
+
+/**
+ * Returns the set of ID references found in the FO Tree.
+ * @return the ID references
+ */
+Set getIDReferences();
}
1.16 +1 -1 xml-fop/src/java/org/apache/fop/fo/FObj.java
Index: FObj.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FObj.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- FObj.java 24 Aug 2003 22:15:51 - 1.15
+++ FObj.java 1 Sep 2003 19:21:07 - 1.16
@@ -285,7 +285,7 @@
if (prop != null) {
String str = prop.getString();
if (str != null !str.equals()) {
-Set idrefs = foInputHandler.getIDReferences();
+Set idrefs = getFOTreeControl().getIDReferences();
if (!idrefs.contains(str)) {
id = str;
idrefs.add(id);
cvs commit: xml-fop/src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java FOTreeControl.java FObjMixed.java GenericShorthandParser.java InlineCharIterator.java OneCharIterator.java PropertyManager.java XMLElement.java
vmote 2003/09/01 11:33:06
Modified:src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
FOTreeControl.java FObjMixed.java
GenericShorthandParser.java InlineCharIterator.java
OneCharIterator.java PropertyManager.java
XMLElement.java
Log:
checkstyle/javadoc changes only
Revision ChangesPath
1.10 +4 -2 xml-fop/src/java/org/apache/fop/fo/FONode.java
Index: FONode.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FONode.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- FONode.java 22 Aug 2003 17:42:41 - 1.9
+++ FONode.java 1 Sep 2003 18:33:05 - 1.10
@@ -61,9 +61,8 @@
// FOP
import org.apache.fop.apps.FOPException;
-import org.apache.fop.fo.FOTreeControl;
import org.apache.fop.util.CharUtilities;
-import org.apache.fop.apps.*;
+import org.apache.fop.apps.FOUserAgent;
/**
* base class for nodes in the XML tree
@@ -197,6 +196,9 @@
return null;
}
+/**
+ * @return an iterator for the characters in this node
+ */
public CharIterator charIterator() {
return new OneCharIterator(CharUtilities.CODE_EOT);
}
1.15 +2 -2 xml-fop/src/java/org/apache/fop/fo/FOTreeBuilder.java
Index: FOTreeBuilder.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOTreeBuilder.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- FOTreeBuilder.java28 Aug 2003 19:49:44 - 1.14
+++ FOTreeBuilder.java1 Sep 2003 18:33:05 - 1.15
@@ -54,7 +54,6 @@
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
-import org.apache.fop.fo.FOTreeControl;
import org.apache.fop.fo.pagination.Root;
// SAX
@@ -74,7 +73,7 @@
import java.util.Enumeration;
import java.util.Iterator;
import java.util.List;
-import org.apache.fop.apps.*;
+import org.apache.fop.apps.FOUserAgent;
/**
* SAX Handler that passes parsed data to the various
@@ -123,6 +122,7 @@
private FOUserAgent userAgent;
+/** The FOTreeControl object managing the FO Tree that is being built */
public FOTreeControl foTreeControl;
/**
1.5 +37 -12xml-fop/src/java/org/apache/fop/fo/FOTreeControl.java
Index: FOTreeControl.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOTreeControl.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FOTreeControl.java26 Aug 2003 17:15:14 - 1.4
+++ FOTreeControl.java1 Sep 2003 18:33:05 - 1.5
@@ -66,20 +66,45 @@
* with information about the environment, and to keep track of meta-type
* information.
*/
-
public interface FOTreeControl {
-public String fontLookup(String family, String style,
+/**
+ * @param family the font family
+ * @param style the font style
+ * @param weight the font weight
+ * @return the String font name matching the parameters
+ */
+String fontLookup(String family, String style,
int weight);
-public FontMetrics getMetricsFor(String fontName);
-
-public boolean isSetupValid();
-
-public Map getFonts();
-
-public void setBookmarks(Bookmarks bookmarks);
-
-public Bookmarks getBookmarks();
+/**
+ * @param fontName the String containing the font name for which a
+ * FontMetrics object is desired
+ * @return the FontMetrics object matching the fontName parameter
+ */
+FontMetrics getMetricsFor(String fontName);
+
+/**
+ * @return true if the default font has been properly setup
+ */
+boolean isSetupValid();
+
+/**
+ * @return a Map containing the Fonts used in this FO Tree
+ */
+Map getFonts();
+
+/**
+ * Sets the Bookmark object which encapsulates the bookmarks for the FO
+ * Tree.
+ * @param bookmarks the Bookmark object encapsulating the bookmarks for this
+ * FO Tree.
+ */
+void setBookmarks(Bookmarks bookmarks);
+
+/**
+ * @return the Bookmark object encapsulating the bookmarks for the FO Tree.
+ */
+Bookmarks getBookmarks();
}
1.12 +0 -2 xml-fop/src/java/org/apache/fop/fo/FObjMixed.java
Index: FObjMixed.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FObjMixed.java,v
retrieving revision 1.11
cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr LayoutManagerLS.java
vmote 2003/09/01 11:48:10
Modified:src/java/org/apache/fop/layoutmgr LayoutManagerLS.java
Log:
remove some convoluted and unnecessary logic -- we already know the Document that is
being processed
Revision ChangesPath
1.12 +4 -8 xml-fop/src/java/org/apache/fop/layoutmgr/LayoutManagerLS.java
Index: LayoutManagerLS.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/LayoutManagerLS.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- LayoutManagerLS.java 27 Aug 2003 19:00:10 - 1.11
+++ LayoutManagerLS.java 1 Sep 2003 18:48:10 - 1.12
@@ -149,13 +149,9 @@
data.addSubData(createBookmarkData(out));
}
// add data to area tree for resolving and handling
-if (document.getBookmarks().getFOInputHandler() instanceof FOTreeHandler) {
-FOTreeHandler foth =
(FOTreeHandler)document.getBookmarks().getFOInputHandler();
-Document doc = (Document)foth.foTreeControl;
-AreaTree at = doc.getAreaTree();
-at.addTreeExtension(data);
-data.setAreaTree(at);
-}
+AreaTree at = document.getAreaTree();
+at.addTreeExtension(data);
+data.setAreaTree(at);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
