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 2006/08/23 02:10:25 UTC
svn commit: r433810 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo:
FOText.java FObjMixed.java
Author: adelmelle
Date: Tue Aug 22 17:10:20 2006
New Revision: 433810
URL: http://svn.apache.org/viewvc?rev=433810&view=rev
Log:
Cleanup: removal of suspicious static in FOText
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FObjMixed.java
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java?rev=433810&r1=433809&r2=433810&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java Tue Aug 22 17:10:20 2006
@@ -27,7 +27,6 @@
import org.apache.fop.apps.FOPException;
import org.apache.fop.datatypes.Length;
import org.apache.fop.fo.flow.Block;
-import org.apache.fop.fo.pagination.Root;
import org.apache.fop.fo.properties.CommonFont;
import org.apache.fop.fo.properties.CommonHyphenation;
import org.apache.fop.fo.properties.CommonTextDecoration;
@@ -44,9 +43,6 @@
* onto references to the character data in this object
* longer than the lifetime of the object itself, causing
* excessive memory consumption and OOM errors.
- *
- * @author unascribed
- * @author <a href="mailto:mark-fop@inomial.com">Mark Lillywhite</a>
*/
public class FOText extends FONode {
@@ -70,12 +66,17 @@
* to be processed.
*
* This value is originally equal to ca.length, but becomes
- * decremented during between-word whitespace removal by the flow.Block class,
- * via the TextCharIterator.remove() method below.
+ * decremented during between-word whitespace removal by the
+ * XMLWhiteSpaceHandler via the TextCharIterator.remove()
+ * method below.
*/
public int endIndex = 0;
- // The value of properties relevant for character.
+ /** properties relevant for PCDATA */
+ /* TODO: these are basically always the same as the parent FObj or FObjMixed
+ * so maybe those can be removed, and the accessors could
+ * dispatch the call to the parent?
+ */
private CommonFont commonFont;
private CommonHyphenation commonHyphenation;
private Color color;
@@ -87,16 +88,6 @@
private Property wordSpacing;
private int wrapOption;
private Length baselineShift;
- // End of property values
-
- /**
- * Keeps track of the last FOText object created within the current
- * block. This is used to create pointers between such objects.
- * TODO: As soon as the control hierarchy is straightened out, this static
- * variable needs to become an instance variable in some parent object,
- * probably the page-sequence.
- */
- private static FOText lastFOTextProcessed = null;
/**
* Points to the previous FOText object created within the current
@@ -227,23 +218,21 @@
}
/**
- * This method is run as part of the ancestor Block's flushText(), to create xref pointers to
- * the previous FOText objects within the same Block
+ * This method is run as part of the ancestor Block's flushText(), to
+ * create xref pointers to the previous FOText objects within the same Block
*/
protected void createBlockPointers(Block ancestorBlock) {
this.ancestorBlock = ancestorBlock;
// if the last FOText is a sibling, point to it, and have it point here
- if (lastFOTextProcessed != null) {
- if (lastFOTextProcessed.ancestorBlock == this.ancestorBlock) {
- prevFOTextThisBlock = lastFOTextProcessed;
+ if (ancestorBlock.lastFOTextProcessed != null) {
+ if (ancestorBlock.lastFOTextProcessed.ancestorBlock
+ == this.ancestorBlock) {
+ prevFOTextThisBlock = ancestorBlock.lastFOTextProcessed;
prevFOTextThisBlock.nextFOTextThisBlock = this;
} else {
prevFOTextThisBlock = null;
}
}
- // save the current node in static field so the next guy knows where
- // to look
- lastFOTextProcessed = this;
return;
}
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FObjMixed.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FObjMixed.java?rev=433810&r1=433809&r2=433810&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FObjMixed.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FObjMixed.java Tue Aug 22 17:10:20 2006
@@ -36,6 +36,10 @@
/** Used for white-space handling; start CharIterator at node ... */
protected FONode currentTextNode;
+ /** Used in creating pointers between subsequent FOText nodes
+ * in the same Block (for handling text-transform) */
+ protected FOText lastFOTextProcessed = null;
+
/**
* @param parent FONode that is the parent of this object
*/
@@ -91,6 +95,7 @@
ft = null;
if (getNameId() == FO_BLOCK) {
lft.createBlockPointers((org.apache.fop.fo.flow.Block) this);
+ this.lastFOTextProcessed = lft;
} else if (getNameId() != FO_MARKER
&& getNameId() != FO_TITLE
&& getNameId() != FO_BOOKMARK_TITLE) {
@@ -106,6 +111,7 @@
}
if (foNameId == FO_BLOCK) {
lft.createBlockPointers((org.apache.fop.fo.flow.Block) fo);
+ ((FObjMixed) fo).lastFOTextProcessed = lft;
} else if (foNameId == FO_PAGE_SEQUENCE) {
log.error("Could not create block pointers."
+ " FOText w/o Block ancestor.");
@@ -142,6 +148,5 @@
*/
public CharIterator charIterator() {
return new RecursiveCharIterator(this);
- }
-
+ }
}
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: svn commit: r433810 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo:
FOText.java FObjMixed.java
Posted by Chris Bowditch <bo...@hotmail.com>.
Andreas L Delmelle wrote:
> On Aug 24, 2006, at 19:45, Andreas L Delmelle wrote:
>
>> On Aug 24, 2006, at 15:08, Chris Bowditch wrote:
>>
>> Hi Chris,
>>
>>> <snip />
>>> Well I'm not sure if its one of your recent changes thats to blame,
>>> but I've just noticed that simple tables (test file attached) appear
>>> to be issuing a SEVERE message to the log, i.e.
>>>
>>> 24-Aug-2006 14:04:41 org.apache.fop.datatypes.LengthBase getBaseLength
>>> SEVERE: getBaseLength called without context
>>
>>
>> Just checked this, and it seems that this has to do with the
>> percentage ipd. Somehow, propertyList.get().getLengthRange() tries to
>> resolve the percentage at that point, but does not have any context
>> yet to do so...
>
>
> Got it. Was introduced with checking bpd/ipd for negative values
> (r433385).
>
> Should be fixed now.
Thanks for a swift turnaround Andreas!
Chris
Re: svn commit: r433810 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FOText.java FObjMixed.java
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 24, 2006, at 19:45, Andreas L Delmelle wrote:
> On Aug 24, 2006, at 15:08, Chris Bowditch wrote:
>
> Hi Chris,
>
>> <snip />
>> Well I'm not sure if its one of your recent changes thats to
>> blame, but I've just noticed that simple tables (test file
>> attached) appear to be issuing a SEVERE message to the log, i.e.
>>
>> 24-Aug-2006 14:04:41 org.apache.fop.datatypes.LengthBase
>> getBaseLength
>> SEVERE: getBaseLength called without context
>
> Just checked this, and it seems that this has to do with the
> percentage ipd. Somehow, propertyList.get().getLengthRange() tries
> to resolve the percentage at that point, but does not have any
> context yet to do so...
Got it. Was introduced with checking bpd/ipd for negative values
(r433385).
Should be fixed now.
Cheers,
Andreas
Re: svn commit: r433810 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FOText.java FObjMixed.java
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 24, 2006, at 15:08, Chris Bowditch wrote:
Hi Chris,
> <snip />
> Well I'm not sure if its one of your recent changes thats to blame,
> but I've just noticed that simple tables (test file attached)
> appear to be issuing a SEVERE message to the log, i.e.
>
> 24-Aug-2006 14:04:41 org.apache.fop.datatypes.LengthBase getBaseLength
> SEVERE: getBaseLength called without context
Just checked this, and it seems that this has to do with the
percentage ipd. Somehow, propertyList.get().getLengthRange() tries to
resolve the percentage at that point, but does not have any context
yet to do so...
I'll look a bit deeper into it. See if we can avoid the error message
somehow.
This could have been there for quite some time. The percentage
resolution is attempted again during layout, and won't give an error
message there, because the context is available. So the tests would
pass.
Later,
Andreas
Re: svn commit: r433810 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo:
FOText.java FObjMixed.java
Posted by Chris Bowditch <bo...@hotmail.com>.
Andreas L Delmelle wrote:
> On Aug 23, 2006, at 02:10, adelmelle@apache.org wrote:
>
<snip/>
> No tests broke, but I'm not sure how to test whether this change had
> any unintended side-effects...
Well I'm not sure if its one of your recent changes thats to blame, but
I've just noticed that simple tables (test file attached) appear to be
issuing a SEVERE message to the log, i.e.
24-Aug-2006 14:04:41 org.apache.fop.datatypes.LengthBase getBaseLength
SEVERE: getBaseLength called without context
I traced the call back to LengthBase.getBaseLength to Table.bind()
The table still gets generated but the message makes you think it failed.
Chris
Re: svn commit: r433810 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FOText.java FObjMixed.java
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 23, 2006, at 02:10, adelmelle@apache.org wrote:
> Author: adelmelle
> Date: Tue Aug 22 17:10:20 2006
> New Revision: 433810
>
> URL: http://svn.apache.org/viewvc?rev=433810&view=rev
> Log:
> Cleanup: removal of suspicious static in FOText
Finally went ahead with this one as well. Up to now, I was a bit
reluctant to remove it, since I didn't fully get its intention. Seems
to be used only during text-transform handling.
Saving lastFOTextProcessed in the ancestorBlock seemed like a much
better solution, and should AFAICT, have exactly the same net effect.
No tests broke, but I'm not sure how to test whether this change had
any unintended side-effects...
Later,
Andreas