Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml

2005-02-02 Thread Chris Bowditch
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: Problem with newlines in TextLayoutManager

2005-02-02 Thread Chris Bowditch
Jeremias Maerki wrote:
Luca (and maybe Finn),
Not forgetting Simon :-)
snip/
Is there some reason why my patch below would make anything worse? It
seems to fix my problem here and all my test cases still pass (at least
the ones that passed before).
I dont know the answer to your question. However, I wondered if you have 
reviewed the comments/todo list left by Luca in bugzilla?

http://issues.apache.org/bugzilla/show_bug.cgi?id=27901
This bug is still open, but there are some others which may help understand 
what is going on here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=28021
http://issues.apache.org/bugzilla/show_bug.cgi?id=28130
Hope this helps a bit,
Chris



Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml

2005-02-02 Thread Jeremias Maerki
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

2005-02-02 Thread Luca Furini

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

2005-02-02 Thread The Web Maestro
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

2005-02-02 Thread Jeremias Maerki
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: XML Graphics: board concerns

2005-02-02 Thread Gil Loureiro

Return Receipt
   
Your  RE: XML Graphics: board concerns 
document   
:  
   
was   Gil Loureiro/EDINFOR 
received   
by:
   
at:   02/02/2005 04:00:42 PM   
   







Dual Column Layout

2005-02-02 Thread Puppala, Kumar (LNG-DAY)
I am having difficulty understanding how the dual column layout is
implemented in FOP.

Scenario 1:
I set the property column-count=2 on my fo:region-body object. As such the
text appears in dual column format. If I have the page totally filled out,
then everything seems to be fine. But if my document does not contain enough
text (usually the last page in my document), the text does not seem to be
evenly distributed in both the columns. It first tries to fill the left
column and then tries to fill the right column if there is an additional
text. If this page is the last page and we don't have any additional text,
the renderer should try to distribute it evenly on both columns. That is the
behavior I have seem on other viewers.

Scenario 2:
If I keep switching between dual and single columns on the same page ( using
the span=all property on an fo:block within a page), the distribution
between the columns seems to be happening but does not happen accurately. I
see more text on the left hand column than on the right hand column. Doing
this would leave additional blank space on the right hand column before we
switch to single column layout.

Can someone help me in understanding this behavior and if there is anything
I can do to fix it?

Thanks,
Kumar Puppala



Re: Dual Column Layout

2005-02-02 Thread J.Pietschmann
Puppala, Kumar (LNG-DAY) wrote:
I am having difficulty understanding how the dual column layout is
implemented in FOP.
Scenario 1:
I set the property column-count=2 on my fo:region-body object. As such the
text appears in dual column format. If I have the page totally filled out,
then everything seems to be fine. But if my document does not contain enough
text (usually the last page in my document), the text does not seem to be
evenly distributed in both the columns. It first tries to fill the left
column and then tries to fill the right column if there is an additional
text.
As mandated by the spec.
If this page is the last page and we don't have any additional text,
the renderer should try to distribute it evenly on both columns. That is the
behavior I have seem on other viewers.
This can be forced by adding an empty block with span=all at the
end of the flow.

Scenario 2:
If I keep switching between dual and single columns on the same page ( using
the span=all property on an fo:block within a page), the distribution
between the columns seems to be happening but does not happen accurately. I
see more text on the left hand column than on the right hand column. Doing
this would leave additional blank space on the right hand column before we
switch to single column layout.
This is due to a simple algorithm for balancing. Getting column
balancing even somewhat right is quite complicated.
J.Pietschmann


RE: Dual Column Layout

2005-02-02 Thread Puppala, Kumar (LNG-DAY)
J.Pietschmann,
Thanks for your response. Is the algorithm for column-balancing
going to be change in the next release to make it work more accurately? 

Thanks,
Kumar Puppala


-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 02, 2005 3:54 PM
To: fop-dev@xml.apache.org
Subject: Re: Dual Column Layout

Puppala, Kumar (LNG-DAY) wrote:
 I am having difficulty understanding how the dual column layout is
 implemented in FOP.
 
 Scenario 1:
 I set the property column-count=2 on my fo:region-body object. As such
the
 text appears in dual column format. If I have the page totally filled out,
 then everything seems to be fine. But if my document does not contain
enough
 text (usually the last page in my document), the text does not seem to be
 evenly distributed in both the columns. It first tries to fill the left
 column and then tries to fill the right column if there is an additional
 text.

As mandated by the spec.

 If this page is the last page and we don't have any additional text,
 the renderer should try to distribute it evenly on both columns. That is
the
 behavior I have seem on other viewers.

This can be forced by adding an empty block with span=all at the
end of the flow.


 Scenario 2:
 If I keep switching between dual and single columns on the same page (
using
 the span=all property on an fo:block within a page), the distribution
 between the columns seems to be happening but does not happen accurately.
I
 see more text on the left hand column than on the right hand column. Doing
 this would leave additional blank space on the right hand column before we
 switch to single column layout.

This is due to a simple algorithm for balancing. Getting column
balancing even somewhat right is quite complicated.

J.Pietschmann


Re: Dual Column Layout

2005-02-02 Thread Jeremias Maerki
It's going to be rewritten from scratch because the layout code is all
new. Just don't ask when this is going to happen. :-) We would be glad
to accept any help. It could speed up the process.

On 02.02.2005 22:53:20 Puppala, Kumar (LNG-DAY) wrote:
 Is the algorithm for column-balancing
 going to be change in the next release to make it work more accurately? 


Jeremias Maerki