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

Reply via email to