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

Reply via email to