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
