Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
I see my error; I did not realize the influence of the retained padding. This situation is very similar to tables with their headers and footers. There needs to be a penalty equal to the widths of the padding-after and padding-before below each block. A block equal to the widths of the padding-after and padding-before comes at the end of the block. I do not have time to look up the details, as I am going away for a few days. Regards, Simon On Thu, Sep 15, 2005 at 08:58:37AM +0200, Jeremias Maerki wrote: On 14.09.2005 22:44:07 Simon Pepping wrote: On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote: Can one of the Knuth specialist please review my element list in the new test case below? Thanks. The element list seems OK to me. The first page also seems OK to me. What is strange is that the first line on the second page has vpos=190800, i.e. 6 below the end of the last line on page 1. Clearly 3 padding after and padding before are added. Is this not a problem of the area part of the code? I didn't even look at the area tree, but you're right vpos is a bit strange, though I get 162000, not 190800. :-) But I wouldn't put too much weight on the vpos attribute since it simply writes out the currentBPPosition. I'm going to investigate that a little more. I believe we can't start talking about something wrong in the area part if the element list is wrong in the first place. Both parts need to be synchronized. That's why it's important not only to test the area tree but also the element lists. Otherwise, you get strange line or page breaking decisions and you don't know why. Thanks for the feedback! I realized with this bug that I need to take borders and padding from parent LMs into account when I'm trying to create the right element lists for spaces. Looks like we need a stack on the LayoutContext for non-conditional borders and paddings. ATM I believe we will end up extending the use of unresolved list elements which get resolved to normal Knuth elements prior to breaking. Otherwise, the code gets too complicated if the complex break possibilities (like pen-glue-box-PEN-glue) are becoming more common. I will write something up on the Wiki about that. BTW, if you run this test, the output looks good, but add two or three additional lines and you'll see the problem in the output, too. Regards, Simon Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
On 14.09.2005 22:44:07 Simon Pepping wrote: On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote: Can one of the Knuth specialist please review my element list in the new test case below? Thanks. The element list seems OK to me. The first page also seems OK to me. What is strange is that the first line on the second page has vpos=190800, i.e. 6 below the end of the last line on page 1. Clearly 3 padding after and padding before are added. Is this not a problem of the area part of the code? I didn't even look at the area tree, but you're right vpos is a bit strange, though I get 162000, not 190800. :-) But I wouldn't put too much weight on the vpos attribute since it simply writes out the currentBPPosition. I'm going to investigate that a little more. I believe we can't start talking about something wrong in the area part if the element list is wrong in the first place. Both parts need to be synchronized. That's why it's important not only to test the area tree but also the element lists. Otherwise, you get strange line or page breaking decisions and you don't know why. Thanks for the feedback! I realized with this bug that I need to take borders and padding from parent LMs into account when I'm trying to create the right element lists for spaces. Looks like we need a stack on the LayoutContext for non-conditional borders and paddings. ATM I believe we will end up extending the use of unresolved list elements which get resolved to normal Knuth elements prior to breaking. Otherwise, the code gets too complicated if the complex break possibilities (like pen-glue-box-PEN-glue) are becoming more common. I will write something up on the Wiki about that. BTW, if you run this test, the output looks good, but add two or three additional lines and you'll see the problem in the output, too. Regards, Simon Jeremias Maerki
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
Can one of the Knuth specialist please review my element list in the new test case below? Thanks. BTW, if you run this test, the output looks good, but add two or three additional lines and you'll see the problem in the output, too. On 14.09.2005 17:02:28 jeremias wrote: Author: jeremias Date: Wed Sep 14 08:02:24 2005 New Revision: 280872 URL: http://svn.apache.org/viewcvs?rev=280872view=rev Log: Ouch. The penalties are completely wrong if a higher-level block defines non-conditional padding. Added: xmlgraphics/fop/trunk/test/layoutengine/testcases/block_padding_2.xml (with props) Modified: xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.txt snip/ Jeremias Maerki
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote: Can one of the Knuth specialist please review my element list in the new test case below? Thanks. The element list seems OK to me. The first page also seems OK to me. What is strange is that the first line on the second page has vpos=190800, i.e. 6 below the end of the last line on page 1. Clearly 3 padding after and padding before are added. Is this not a problem of the area part of the code? BTW, if you run this test, the output looks good, but add two or three additional lines and you'll see the problem in the output, too. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
