Thanks for your feedback, Simon. I know about the empty block problem.
I even documented it (sort of) in the commit message ("block w=0 causes
a fence right now although it shouldn't."). I think it relatively easily
dealt with. The box with w=0 can easily be recognized in SpaceResolver
and handled as needed. I'll document this with a test case.On 17.10.2005 20:24:43 Simon Pepping wrote: > On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote: > > I finally uploaded my space resolution work so far. It's still not > > finished. When you go through the details you always find more stuff to > > look into and to fix. But most of it works now and is available for > > review while I work on the remaining issues. I assume there is room for > > optimization here and there. So don't hesitate to jump in and help. The > > enabled test cases all pass. > > > > What I forgot to include in the commit message: I changed from empty > > block areas to space-before and space-after traits! This caused a lot of > > changed checks in the test cases. That was a project on its own. :-) But > > the area trees are much clearer now. > > That is a lot of code. The result looks very robust. > > The following case seems to present a problem: > > ... > </fo:block> > <fo:block/> > <fo:block space-before="10pt" background-color="#B55555"> > ... > > The empty block seems to split the stacking constraint into two > constraints, one containing the space-after of the preceding block, > and another containing the space-before of the following block. IMHO, > this should be a single stacking constraint, case 3d in the spec., > section 4.2.5, Stacking Constraints. > > When the empty block has space-before and/or space-after, it results > even in a rule in the output. > > Regards, Simon > > -- > Simon Pepping > home page: http://www.leverkruid.nl Jeremias Maerki
