You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Vincent Hennebert <vh...@gmail.com> on 2010/11/01 21:38:38 UTC
Re: Padding-left ignored inside repeating table header
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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Padding-left ignored inside repeating table header
Posted by Matthias Reischenbacher <ma...@gmx.at>.
Hi Vincent,
thanks a lot for your feedback. I wasn't very happy either with the solution
I had come up with.
I followed your idea and added a check inside the addAreas method if the
first position of the knuth sequence is present. I added the patch to the
bugzilla entry.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50196
Execution of the layout unit test shows no regressions. BTW, all unit tests
terminate with an error if the file system path containing the FOP code has
white spaces.
Regards,
Matthias
Vincent Hennebert-2 wrote:
>
> 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,
> Vincent
>
> [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
>>>
>>>
>>
>
>
--
View this message in context: http://old.nabble.com/Re%3A-Padding-left-ignored-inside-repeating-table-header-tp30247045p30326865.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Padding-left ignored inside repeating table header
Posted by Vincent Hennebert <vh...@gmail.com>.
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,
Vincent
[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
>>
>>
>
Re: Padding-left ignored inside repeating table header
Posted by Matthias Reischenbacher <ma...@gmx.at>.
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
>
>
--
View this message in context: http://old.nabble.com/Re%3A-Padding-left-ignored-inside-repeating-table-header-tp30247045p30282695.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Padding-left ignored inside repeating table header
Posted by Vincent Hennebert <vh...@gmail.com>.
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
Re: Padding-left ignored inside repeating table header
Posted by Matthias Reischenbacher <ma...@gmx.at>.
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?
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?
Thanks for your help...
Matthias
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
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Padding-left-ignored-inside-repeating-table-header-tp30077409p30202938.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Padding-left ignored inside repeating table header
Posted by Vincent Hennebert <vh...@gmail.com>.
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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Padding-left ignored inside repeating table header
Posted by Matthias Reischenbacher <ma...@gmx.at>.
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?
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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Padding-left-ignored-inside-repeating-table-header-tp30077409p30109852.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org