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
