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. 60000 below the end of the last line on page > > 1. Clearly 30000 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