Hi Matthias,

I did have something in mind along the lines of this. Well done in an
area of the code that’s all but easy to understand.

This solution seems to do the job, but it has shortcomings that will
cause maintenance issues:
• it adds yet another method to the LayoutManager interface that is
  overloaded already. All the descendants of that interface must
  implement this method that seems to be of actual use only to
  InlineLayoutManager. I’d rather fix InlineLM instead.
• the resetChildAreas boolean must be passed around in RowPainter and
  TableContentLM. Yet another parameter on methods that already have
  quite a few. And again just because of one class.
• given the complexity of the layout engine I wouldn’t be surprised if
  that method had side effects in other situations. Side effects that,
  needless to say, would be very hard to diagnose...

All that trouble is due to that areaCreated boolean in InlineLM, so it
would be good if we could get rid of it. In fact, we’re not so much
interested in knowing whether InlineLM has already created areas or not,
but rather if it’s creating its first area [1].

Maybe the following could work: Every layout manager wraps the Knuth
elements returned by its child LMs in its own Position instances (see
KnuthSequence.wrapPositions). There might be a way for InlineLM to mark
the first position it’s creating as special, so that it can recognize it
when iterating over positions in the addAreas method. That should be
enough for it to know whether it’s creating its first area or not, i.e.,
whether it must apply special treatment for borders, paddings, etc.

Feel free to investigate that approach and ask questions on this mailing
lists if things are not clear. We will try our best to answer them...

During your experimentations the ‘ant junit-layout-standard’ target is
there for you to check that no regression has been introduced in the
layout engine. It will be quicker to run than the whole test suite,
which you can run only once at the end.

Good luck,

[1] see the is-first trait at http://www.w3.org/TR/xsl11/#area-common

On 22/11/10 21:16, Matthias Reischenbacher wrote:
> Hi Vincent,
> thanks for your explanations! 
> I had a further look into the code in order to figure out what could be a
> possible way to fix this. What I've come up with, is to reset the
> areaCreated variable before the table header (or footer) is layouted the
> second time.
> Could you please check if I'm going into the right direction here before
> adding a patch to the bugzilla entry? My insight into the whole layouting
> process is still very narrow....
> http://old.nabble.com/file/p30282695/repeating_table_part.patch
> repeating_table_part.patch 
> Thanks,
> Matthias
> Vincent Hennebert-2 wrote:
>> Hi Matthias,
>> [Moving to fop-dev so as not to scare users with gory details ;-) ]
>> Thanks for you analysis of this problem, and sorry for the delay.
>> On 12/11/10 20:10, Matthias Reischenbacher wrote:
>>> Hi Vincent,
>>> I had a look at the code you pointed me to and I think I found a possible
>>> reason for the problem but I'm not sure how to fix it.
>>> When the addAreas() method of the InlineLayoutManager is called, this
>>> code
>>> line is executed:
>>> setTraits(areaCreated, lastPos == null || !isLast(lastPos));
>>> For the first table header the areaCreated variable is correctly set to
>>> false and the left padding is being applied. But for the repeating table
>>> header the value is false and therefore padding isn't applied.
>>> So my questions are:
>>> 1. Is it correct that the same InlineLayoutManager instance is used for
>>> both
>>> table headers?
>> In theory, yes. InlineLM produces a sequence of Knuth elements that
>> represents its content. That sequence will be the same for every
>> repetition of a table header/footer.
>> The problem is at the creation of the area tree. Borders and padding
>> apply differently to the first occurrence of an element and the remaining
>> ones. For example, say you have an fo:inline with a border-start that is
>> broken over two lines. By default the border must be painted for the
>> first line but not for the second one. That’s the purpose of that
>> areaCreated boolean and isLast.
>>> 2. If using the same instance is ok, is there any way to know that a
>>> page/column break had occurred? Does the layout context provide a method
>>> for
>>> knowing this?
>> That’s the tricky part. To my knowledge there is no way of figuring that
>> out. Determining whether the first/last area is being created should
>> probably be done differently, but I’m not too clear on how to do it.
>> Sorry. Fortunately you have a workaround for the problem you were facing
>> in the first place.
>>> Thanks for your help...
>>> Matthias
>> Vincent
>>> Vincent Hennebert-2 wrote:
>>>> Hi Matthias,
>>>> On 02/11/10 00:22, Matthias Reischenbacher wrote:
>>>>> Hi Vincent,
>>>>> thanks for confirming...
>>>>> Here is the bugzilla entry:
>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50196
>>>>> Could you please point me to the releated FOP classes, so I can give it
>>>>> an
>>>>> attempt to fix it on my own?
>>>> I’m not too sure actually. I suppose I would look in
>>>> org.apache.fop.layoutmgr.inline.InlineLayoutManager, especially the
>>>> getNextKnuthElements method, and see how padding is handled. Then
>>>> o.a.f.layoutmgr.table.TableContentLayoutManager that manages the
>>>> contents of the table header and footer. Then the respective addAreas
>>>> methods that create the area tree. Check what padding has become at that
>>>> stage.
>>>> I hope this helps,
>>>> Vincent
>>>>> Thanks & Best regards,
>>>>> Matthias
>>>>> Vincent Hennebert-2 wrote:
>>>>>> Hi Matthias,
>>>>>> This is a bug. Could you please file a bug report on Bugzilla:
>>>>>> https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop
>>>>>> Thanks,
>>>>>> Vincent
>>>>>> On 28/10/10 15:45, MatthiasR wrote:
>>>>>>> Hi,
>>>>>>> I have a problem when using padding-left on a fo:inline element
>>>>>>> inside
>>>>>>> a
>>>>>>> repeating table header. The padding-left value is ignored on the
>>>>>>> repeated
>>>>>>> table header on the next page.
>>>>>>> Test case:  http://old.nabble.com/file/p30077409/bg_bug.fo bg_bug.fo 
>>>>>>> PDF result file:  http://old.nabble.com/file/p30077409/bg_bug.pdf
>>>>>>> bg_bug.pdf 
>>>>>>> I'm aware that there are other ways to move the text to the right but
>>>>>>> it
>>>>>>> would be nice if somebody can give me some feedback if this should be
>>>>>>> considered a bug.
>>>>>>> Thanks for your help & Regards,
>>>>>>> Matthias Reischenbacher

Reply via email to