Hi Matthias,

Looks like you pinpointed the problem, well done. I’ve just submitted
a fix, please test with your real-life file.
http://svn.apache.org/viewvc?rev=1083863&view=rev

On 19/03/11 21:22, Matthias Reischenbacher wrote:
> 
> Hi Andreas,
> 
> thanks a lot for your explanation of how keep conditions are enforced!
> 
> Today I had been looking at the same code as you and I found it odd that the
> table keep condition is only taken into account inside
> TableStepper.getCombinedKnuthElementsForRowGroup() if the rowFinished value
> is set to false. Do you have any idea what rowFinished means in this
> context? When debugging the code with my test case the value of rowFinished
> is always true and therefore the if statement seems to be dead code.

This means that the end of a table-row has been reached. That is, all
the content of all the cell ending on that row has been handled. If you
are talking about the test case you posted on the users list, then you
always get true because all your cells are one line, so the end is
immediately reached. Try again with cells containing several blocks of
text.


> Do you think it would be a solution to just move out lines 250 and 252 of
> the if statement and execute it always.

Yes indeed, this is what I did.

In theory it would be better to handle table keeps in a table-related
class (TableLM or TableContentLM), but it is impractical to modify the
list of Knuth elements afterwards.


> Perhaps then the additional keep
> condition handling inside TableContentLM.getKnuthElementsForRowIterator()
> could be removed?

No, it’s needed to handle keeps between row groups. Loosely speaking
a row group is the smallest set of table rows that are spanned by cells.
Usually a row group is the same as a row, but it may become more
complicated when cells span several rows. For example:
    __________________________________
    |          |          |          |
    |          |__________|__________|
    |          |          |          |
    |__________|__________|          |
    |          |          |          |
    |__________|__________|__________|


> Thanks & Regards,
> Matthias

Thanks for investigating this.

Vincent



> Andreas Delmelle-2 wrote:
>>
>> On 18 Mar 2011, at 00:30, Matthias Reischenbacher wrote:
>>
>>> <snip />
>>
>> FWIW: I was just playing with the example, and noticed my suggestion
>> --using keep.within-column-- does not help.
>>
>> This means, as Vincent suspects (IIC), that the culprit is the code that
>> takes care of generating the element list in case of row-spanning cells,
>> which inadvertently generates break-possibilities (i.e. does not take into
>> account the keep that is dominating the ancestor fo:table)
>>
>> Comparing the case with and without row-span in a debug session reveals
>> that, with row-span all BreakElements have penalty value 0, whereas
>> without row-span, we get INFINITE, as expected.
>>
>> Looking deeper, in TableContentLM.getKnuthElementsForRowIterator(), notice
>> that the case with row-span produces only one row-group, so the code that
>> would set the keep constraint from the table --in the while loop, line
>> 250-- never gets executed. The RowGroupLayoutManager gets passed a
>> LayoutContext that is not properly initialized (keep="auto").
>>
>>
>> Regards,
>>
>> Andreas
>> ---
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>>
>>
>>
> 

Reply via email to