Re: testcases

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Thanks, Simon.
> 
> And fop-devs, also note that you are allowed (and
> encouraged) to correct,
> modify, improve and add test cases yourself. :-)
> 

Can we remove some too?!?  ;)

Glen

Re: testcases

[Jeremias Maerki]

Thanks, Simon.

And fop-devs, also note that you are allowed (and encouraged) to correct,
modify, improve and add test cases yourself. :-)

On 12.02.2005 14:25:12 Simon Pepping wrote:
> Jeremias,
> 
> Note that you can use the ancestor axis:
> xpath="//text[. = 'line1']/ancestor::pageViewport/@nr" 
> instead of 
> xpath="//text[. = 'line1']/../../../../../../../../../@nr"


Jeremias Maerki

testcases

[Simon Pepping]

Jeremias,

Note that you can use the ancestor axis:
xpath="//text[. = 'line1']/ancestor::pageViewport/@nr" 
instead of 
xpath="//text[. = 'line1']/../../../../../../../../../@nr"

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

page breaks (was: Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking4.xml)

[Jeremias Maerki]

I think it should be relatively simple to rearrange PSLM to set up the
right page before the call to getNextBreakPoss(). What I'm wondering,
though, is why the breaks are handled during getParentArea using
information in Traits on areas and not through BreakPoss instances
during getNextBreakPoss() stage. Does anyone know? There are no such
traits described in the spec that I could find in a quick fly-over. And
IMO it doesn't make sense to do it this way. What am I missing?

On 10.02.2005 14:28:45 Jeremias Maerki wrote:
> Ouch! The PageSequenceLayoutManager has a big problem. It sets the
> reference IPD for the flow once at the beginning and then no more.
> Subsequent pages get their (correct) page master only during addArea
> stage through getParentArea(). But the flow reference area has to be set
> prior to doing any getNextBreakPoss() on a new page. So it's not
> resetPosition() methods that don't behave as I claimed in my earlier CVS
> message (although I found a few strange things with resetPosition() while
> looking at table headers/footers).
> 
> On 10.02.2005 13:52:35 jeremias wrote:
> > jeremias2005/02/10 04:52:35
> > 
> >   Modified:test/layoutengine/testcases normal-breaking4.xml
> >   Log:
> >   Adding an additional block at the end to see if a new block would behave 
> > differently.


Jeremias Maerki

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

[Jeremias Maerki]

Ouch! The PageSequenceLayoutManager has a big problem. It sets the
reference IPD for the flow once at the beginning and then no more.
Subsequent pages get their (correct) page master only during addArea
stage through getParentArea(). But the flow reference area has to be set
prior to doing any getNextBreakPoss() on a new page. So it's not
resetPosition() methods that don't behave as I claimed in my earlier CVS
message (although I found a few strange things with resetPosition() while
looking at table headers/footers).

On 10.02.2005 13:52:35 jeremias wrote:
> jeremias2005/02/10 04:52:35
> 
>   Modified:    test/layoutengine/testcases normal-breaking4.xml
>   Log:
>   Adding an additional block at the end to see if a new block would behave 
> differently.



Jeremias Maerki

Re: cvs commit: xml-fop/test/layoutengine/testcases table-cell5a.xml

[Jeremias Maerki]

Uhm, don't look too closely at my latest test cases. I've made some
mistake in interpretation. Revisiting now...


Jeremias Maerki

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

[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) 
> (Paragraph #1)  (Paragraph #2)provisional-label-separation="0.15cm">
> (Paragraph #3) 
> 
> 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

[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]> - 
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

[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) 
(Paragraph #1) 
(Paragraph #3) 

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 accumulate for each break
-// so the ipd is only added at the end of each LM
-if (bp.getLayoutManager() != lastLM) {
-if 

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

[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
> 
> 
> 
> Chris



Jeremias Maerki

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

[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

Chris

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

[Jeremias Maerki]

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

Re: cvs commit: xml-fop/test/layoutengine/testcases external-graphic1.xml external-graphic2.xml

[Jeremias Maerki]

Oops, sorry! And thanks for catching it.

On 24.01.2005 23:03:56 pietsch wrote:
> pietsch 2005/01/24 14:03:56
> 
>   Modified:.build.xml
>test/layoutengine/testcases external-graphic1.xml
> external-graphic2.xml
>   Log:
>   Replaced absolute image paths with relative


Jeremias Maerki

Re: start-indent inheritance (was: cvs commit: xml-fop/test/layoutengine/testcases block-container3.xml)

[Jeremias Maerki]

There seems to have been some discussion about this in the CR phase:

http://www.w3.org/2001/08/28-XSL-PR-DOC.html (see comment 20)

It would seem that in the case of reference-area generating FOs
start-indent should simply be inherited (comment 20, item 3). In my
example the start-indent of the block-container would be 10pt, which is
then inherited by the orange block. This amounts to an effective 20pt
indent for the orange block and oops, AltSoft is suddenly right. I'm
confused.


Jeremias Maerki

Re: cvs commit: xml-fop/test/layoutengine/testcases block-container3.xml

[Jeremias Maerki]

I'm trying to figure out what the indent of the orange block under the
block-container may be, or rather if our current implementation is
really ok. It's clear that for the yellow block start-indent is 10pt.

5.3.2 says for FOs that don't generate a reference area (ex. fo:block)
the following is true:

start-indent = inherited_value_of(start-indent) + margin-corresponding +
padding-corresponding + border-corresponding-width

start-indent = 10pt = 10pt + 0pt + 0pt + 0pt

For the block-container a different rule applies because it generates a
reference area:

start-indent = margin-corresponding + padding-corresponding +
border-corresponding-width

start-indent = 0pt = 0pt + 0pt + 0pt

Then for the orange block the first formula is used again:

start-indent= 0pt = 0pt + 0pt + 0pt + 0pt

Now, it's interesting to note that XEP and AltSoft interpret this
differently. XEP indents the orange block by 10pt while AltSoft indents
it by 20pt.

You could also note that start-indent is specified as "Inherited: yes"
which somewhat contradicts the second formula above.

XEP seems to use the inherited start-indent for the block-container.
AltSoft seems to do the same and even does the same for the orange block
although rendering then orients itself on the reference area established
by the block-container, thus indenting the orange block by 20pt. AltSoft
is certainly wrong. The question is if XEP is right. :-)

I googled a bit and indeed, there seems be a certain amount of confusion
how this should be handled.

Any thoughts?

On 13.01.2005 16:07:02 jeremias wrote:
> jeremias2005/01/13 07:07:02
> 
>   Added:   test/layoutengine/testcases block-container3.xml
>   Log:
>   Testcase for checking start-indent inheritance across block-containers.
>   
>   Revision  ChangesPath
>   1.1  
> xml-fop/test/layoutengine/testcases/block-container3.xml
>   
>   Index: block-container3.xml
>   ===
>   
>   
>   
>   
> 
>   
> This test checks indents on block-containers.
>   
> 
> 
>   http://www.w3.org/1999/XSL/Format"; 
> xmlns:svg="http://www.w3.org/2000/svg";>
> 
>page-height="5in">
> 
>   
> 
>  white-space-collapse="true">
>   
> 
>   fo:block|fo:block
>   
>  background-color="orange">fo:block|fo:block-container|fo:block
>   
> 
>   
> 
>   
> 
> 
>xpath="/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/block[1]/@ipd"/>
>xpath="/areaTree/pageSequence/pageViewport/page[1]/regionViewport/regionBody/mainReference/span/flow/block[1]/block[1]/@ipda"/>
>   
>   
> 
>   
>   
>   
>   


Jeremias Maerki

Re: cvs commit: xml-fop/test/layoutengine/testcases block-nested1.xml

[Jeremias Maerki]

This test currently fails because nested blocks don't respect the
inherited value of start-indent (XSL-FO 1.0, chapter 5.3.2). I already
have a fix locally but want to improve the code a bit, first, since
there is some amount of redundancy that can be reduced.

On 06.01.2005 17:09:57 jeremias wrote:
> jeremias2005/01/06 08:09:57
> 
>   Added:   test/layoutengine/testcases block-nested1.xml
>   Log:
>   Test for nested blocks with borders, margins and padding.


Jeremias Maerki

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

[Jeremias Maerki]

Looks like the new testing framework already has paid off. padding2.xml
tests border shorthands and currently shows a bug with shorthand
expansion. I'm happy (at least in a certain way).  Glen may
comment again that I'm particular. :-)

Now for fixing that bug

On 06.01.2005 10:47:46 jeremias wrote:
> jeremias2005/01/06 01:47:46
> 
>   Added:   test/layoutengine/testcases padding2.xml
>   Log:
>   Testing padding shorthands.


Jeremias Maerki