You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by ad...@apache.org on 2008/05/01 12:01:51 UTC

svn commit: r652467 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java

Author: adelmelle
Date: Thu May  1 03:01:51 2008
New Revision: 652467

URL: http://svn.apache.org/viewvc?rev=652467&view=rev
Log:
Minor cleanup: remove height/width members and unused getHeight()/getWidth() accessors


Modified:
    xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java

Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java?rev=652467&r1=652466&r2=652467&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java Thu May  1 03:01:51 2008
@@ -48,7 +48,6 @@
     private int breakBefore;
     // private ToBeImplementedProperty clip;
     private int displayAlign;
-    private Length height;
     private LengthRangeProperty inlineProgressionDimension;
     private KeepProperty keepTogether;
     private KeepProperty keepWithNext;
@@ -56,7 +55,6 @@
     private int overflow;
     private Numeric referenceOrientation;
     private int span;
-    private Length width;
     private int writingMode;
     // Unused but valid items, commented out for performance:
     //     private int intrusionDisplace;
@@ -87,7 +85,6 @@
         breakBefore = pList.get(PR_BREAK_BEFORE).getEnum();
         // clip = pList.get(PR_CLIP);
         displayAlign = pList.get(PR_DISPLAY_ALIGN).getEnum();
-        height = pList.get(PR_HEIGHT).getLength();
         inlineProgressionDimension = pList.get(PR_INLINE_PROGRESSION_DIMENSION).getLengthRange();
         keepTogether = pList.get(PR_KEEP_TOGETHER).getKeep();
         keepWithNext = pList.get(PR_KEEP_WITH_NEXT).getKeep();
@@ -95,7 +92,6 @@
         overflow = pList.get(PR_OVERFLOW).getEnum();
         referenceOrientation = pList.get(PR_REFERENCE_ORIENTATION).getNumeric();
         span = pList.get(PR_SPAN).getEnum();
-        width = pList.get(PR_WIDTH).getLength();
         writingMode = pList.get(PR_WRITING_MODE).getEnum();
     }
 
@@ -225,16 +221,6 @@
         return writingMode;
     }
     
-    /** @return the "width" property */
-    public Length getWidth() {
-        return width;
-    }
-
-    /** @return the "height" property */
-    public Length getHeight() {
-        return height;
-    }
-
     /** {@inheritDoc} */
     public String getLocalName() {
         return "block-container";



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org


Re: svn commit: r652467 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java

Posted by Andreas Delmelle <an...@telenet.be>.
On May 1, 2008, at 12:01, adelmelle@apache.org wrote:
> Author: adelmelle
> Date: Thu May  1 03:01:51 2008
> New Revision: 652467
>
> URL: http://svn.apache.org/viewvc?rev=652467&view=rev
> Log:
> Minor cleanup: remove height/width members and unused getHeight()/ 
> getWidth() accessors

Just noticed that these were not used. Since basic correspondence  
mapping is already done during property resolution, I thought it  
would avoid confusion to simply remove them.

Hope nobody minds.

Maybe in the future, we will still need similar accessors, but then  
of the form:

public Length getHeight(int writingMode)
public Length getWidth(int writingMode)

Reason I'm thinking in this direction is that the correspondence  
mapping currently only takes into account the writing-mode on the FO  
itself (or its ancestors in the FO tree: inherited value). One can  
also specify a writing-mode on the region-body for example, and this  
cannot be factored in during property-resolution, since we don't know  
on which page the areas are going to end up...


Cheers

Andreas