Re: Padding-left ignored inside repeating table header
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
Re: Padding-left ignored inside repeating table header
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
Re: Padding-left ignored inside repeating table header
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
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
