Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml
Jeremias Maerki wrote: Just to be clear. This ArrayOutOfBoundsException is not the same problem I've described in my earlier post. I just happened to run into both problems at the same time. Running normal-breaking2.xml with the current code (without my patch) will result in a document with 1 page and the linefeeds displayed as #. So, this test will fail because of the single check in the test case. If someone has an idea about the ArrayOutOfBoundsException, all the better. I'm currently trying to debug that thing. Jeremias: Have you seen the following bug which appears to be the same problem? http://issues.apache.org/bugzilla/show_bug.cgi?id=32174 snip/ Chris
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml
No, it don't think so. That bug happens in getNextBreakPoss() while mine happens in addAdreas(). On 02.02.2005 10:36:41 Chris Bowditch wrote: Jeremias Maerki wrote: Just to be clear. This ArrayOutOfBoundsException is not the same problem I've described in my earlier post. I just happened to run into both problems at the same time. Running normal-breaking2.xml with the current code (without my patch) will result in a document with 1 page and the linefeeds displayed as #. So, this test will fail because of the single check in the test case. If someone has an idea about the ArrayOutOfBoundsException, all the better. I'm currently trying to debug that thing. Jeremias: Have you seen the following bug which appears to be the same problem? http://issues.apache.org/bugzilla/show_bug.cgi?id=32174 snip/ Chris Jeremias Maerki
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml
Jeremias Maerki wrote:
If someone has an idea about the ArrayOutOfBoundsException, all the
better. I'm currently trying to debug that thing.
It's because of this line in LineLM.addAreas():
iCurrParIndex = 0;
If a block has properly handled preserved linefeeds, it will generate more
than one paragraph, so the ArrayList knuthParagraphs will have more than one
element.
In your test file, there will be:
(Paragraph #0) !-- list level 1 --
(Paragraph #1) fo:list-block provisional-distance-between-starts=0.4cm
(Paragraph #2)provisional-label-separation=0.15cm
(Paragraph #3) !-- list item --
If the block is split between two pages, the method LineLM.addAreas will be
called twice: for example, there will be Paragraph #0 and #1 on page 1, and
the others on page 2.
The second time addAreas() is called iCurrParIndex is set to 0, and here is
the bug, because the index stored in the LineBreakPosition lbp refers to an
element in Paragraph #2!
Maybe the best place to store the correct value is inside the
LineBreakPositions; I'm attaching a little patch which modifies the
LineBreakPosition class (and also removes an old, unused method).
As per the ignored newline characters in the TextLM, I really can't remember
why I wrote those lines! :-)
It really looks like they shouldn't be ignored.
HTH
Regards,
Luca
Index: LineLayoutManager.java
===
RCS file:
/home/cvspublic/xml-fop/src/java/org/apache/fop/layoutmgr/LineLayoutManager.java,v
retrieving revision 1.37
diff -u -r1.37 LineLayoutManager.java
--- LineLayoutManager.java 9 Dec 2004 15:53:36 - 1.37
+++ LineLayoutManager.java 2 Feb 2005 14:15:18 -
@@ -95,16 +95,18 @@
*/
private static class LineBreakPosition extends LeafPosition {
// int iPos;
+int iParIndex; // index of the Paragraph this Position refers to
double dAdjust; // Percentage to adjust (stretch or shrink)
double ipdAdjust; // Percentage to adjust (stretch or shrink)
int startIndent;
int lineHeight;
int baseline;
-LineBreakPosition(LayoutManager lm, int iBreakIndex,
+LineBreakPosition(LayoutManager lm, int index, int iBreakIndex,
double ipdA, double adjust, int ind, int lh, int bl)
{
super(lm, iBreakIndex);
// iPos = iBreakIndex;
+iParIndex = index;
ipdAdjust = ipdA;
dAdjust = adjust;
startIndent = ind;
@@ -139,7 +141,6 @@
private int iReturnedLBP = 0;
private int iStartElement = 0;
private int iEndElement = 0;
-private int iCurrParIndex = 0;
private KnuthNode bestDeactivatedNode = null;
@@ -762,6 +763,7 @@
breakpoints.add(insertIndex,
new LineBreakPosition(this,
+ knuthParagraphs.indexOf(par),
lastElementIndex ,
ratio, 0, indent,
lineLead + middlefollow,
@@ -1337,135 +1339,6 @@
}
/**
- * Make a line break for returning as the next break.
- * This makes the line break and calculates the height and
- * ipd adjustment factors.
- *
- * @param prevLineEnd previous line break index
- * @param target the target ipd value
- * @param textalign the text align in operation for this line
- * @return the line break position
- */
-private BreakPoss makeLineBreak(int prevLineEnd, MinOptMax target,
-int textalign) {
-// make a new BP
-// Store information needed to make areas in the LineBreakPosition!
-
-// lead to baseline is
-// max of: baseline fixed alignment and middle/2
-// after baseline is
-// max: top height-lead, middle/2 and bottom height-lead
-int halfLeading = (lineHeight - lead - follow) / 2;
-// height before baseline
-int lineLead = lead + halfLeading;
-// maximum size of top and bottom alignment
-int maxtb = follow + halfLeading;
-// max size of middle alignment below baseline
-int middlefollow = maxtb;
-
-// calculate actual ipd
-MinOptMax actual = new MinOptMax();
-BreakPoss lastBP = null;
-LayoutManager lastLM = null;
-for (Iterator iter = vecInlineBreaks.listIterator(prevLineEnd);
-iter.hasNext();) {
-BreakPoss bp = (BreakPoss) iter.next();
-if (bp.getLead() lineLead) {
-lineLead = bp.getLead();
-}
-if (bp.getTotal() maxtb) {
-maxtb = bp.getTotal();
-}
-if (bp.getMiddle() middlefollow) {
-middlefollow = bp.getMiddle();
-}
-
-// the stacking size of textLM
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml
On Feb 2, 2005, at 2:14 AM, Jeremias Maerki wrote: No, it don't think so. That bug happens in getNextBreakPoss() while mine happens in addAdreas(). I thought it was called addAndreas(to,,list-of-folks,to,send,big,thanks) ;-) Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml
Thanks a lot, Luca. That was it. I was slowly tracking that thing down. I knew already that these start indices were wrong but hadn't figured out how to fix it. And thanks to Chris for the pointers earlier. In the meantime I got to know a lot about the inner workings of the line layout. :-) Good for the next time. On 02.02.2005 15:24:44 Luca Furini wrote: Jeremias Maerki wrote: If someone has an idea about the ArrayOutOfBoundsException, all the better. I'm currently trying to debug that thing. It's because of this line in LineLM.addAreas(): iCurrParIndex = 0; If a block has properly handled preserved linefeeds, it will generate more than one paragraph, so the ArrayList knuthParagraphs will have more than one element. In your test file, there will be: (Paragraph #0) !-- list level 1 -- (Paragraph #1) fo:list-block provisional-distance-between-starts=0.4cm (Paragraph #2)provisional-label-separation=0.15cm (Paragraph #3) !-- list item -- If the block is split between two pages, the method LineLM.addAreas will be called twice: for example, there will be Paragraph #0 and #1 on page 1, and the others on page 2. The second time addAreas() is called iCurrParIndex is set to 0, and here is the bug, because the index stored in the LineBreakPosition lbp refers to an element in Paragraph #2! Maybe the best place to store the correct value is inside the LineBreakPositions; I'm attaching a little patch which modifies the LineBreakPosition class (and also removes an old, unused method). As per the ignored newline characters in the TextLM, I really can't remember why I wrote those lines! :-) It really looks like they shouldn't be ignored. HTH Regards, Luca Jeremias Maerki
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml
Just to be clear. This ArrayOutOfBoundsException is not the same problem I've described in my earlier post. I just happened to run into both problems at the same time. Running normal-breaking2.xml with the current code (without my patch) will result in a document with 1 page and the linefeeds displayed as #. So, this test will fail because of the single check in the test case. If someone has an idea about the ArrayOutOfBoundsException, all the better. I'm currently trying to debug that thing. On 01.02.2005 22:51:38 jeremias wrote: jeremias2005/02/01 13:51:37 Modified:test/layoutengine disabled-testcases.txt Added: test/layoutengine/testcases normal-breaking2.xml Log: Regression test for ArrayOutOfBoundsException in LineLayoutManager.addAreas() (to be fixed). Jeremias Maerki
