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

Reply via email to