You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2005/09/14 17:05:37 UTC
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=280872&view=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
Posted by Simon Pepping <sp...@leverkruid.nl>.
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
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
Posted by Simon Pepping <sp...@leverkruid.nl>.
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?
> 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