DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36403>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36403


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From [EMAIL PROTECTED]  2005-10-27 15:21 -------
(In reply to comment #2)
> Attempting to shed some light on what's happening:
> From the debug output, we can derive that TableStepper.getNextStep() has set
the variable 
> rowBacktrackForLastStep to true (line 513), which in turn leads to 
> TableStepper.getCombinedKnuthElementsForRowGroup() to decrease the activeRow
index (line 249).
> 
> Any subsequent call to TableStepper.getActiveRow() will result in an
AIOOBException.
> 
> Still looking for the exact reason why the backtrack-switch is flipped to
true. Jeremias is probably the 
> only one among us who knows what 'Meeeeep!' means ;-)

Hehe. Actually, it should have been "Meeep, meeep!" because Roadrunner always
does a double meeeep! :-) I've replace the comment with a more verbose debug
message and added a few comments in an attempt to shed a little more light on 
this.

> I'm thinking: either the backtracking itself is out-of-place and shouldn't
happen, or the case where the 
> active row is the first one should be checked for.
> FWIW: simply surrounding TableStepper line 513 with "if (activeRow > 0) { ...
}" seems to resolve the 
> issue, but whether it suffices (i.e. is more than a quick dirty hack), that
I'm not sure about.

You were almost on course. There's an additional aspect here. This case should
actually cause that particular step to be skipped, because borders and padding
allocate more room than the actual step is long which would result in a conflict
situation. I solved this by forcing an INFINITE penalty after the skipped step.
I left a big error sign in there in case a break-before might ruin the fun
there. I'm not sure yet if that's possible at all and what would happen.

Analysis test case on the Wiki documenting a row backtrack situation:
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder2
Hand-written notes with details on the situation (not very verbose, I'm afraid):
http://people.apache.org/~jeremias/fop/NextStepAlgoNotes.pdf

Test case to check this case here:
table_bug36403.xml
(I could actually simplify the case documented in this bug here.)

SVN Revision of the fix:
http://svn.apache.org/viewcvs?rev=328868&view=rev

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to