Space-resolution doesn't work

[Jeremias Maerki <de...@greenmail.ch>]

I think we need to revisit the whole space-resolution story. The current
code is fine for only the simplest of cases. If you look at the 4.3.1
Space-resolution Rules in the spec the example given there shows quite
clearly IMO that we probably can't just rely on the right combination of
Knuth elements to resolved the spaces. Especially rule 3 is quite nasty.
I'll start from scratch to come up with a better strategy of
implementing these rules. I'll probably start by documenting a few cases
in the Wiki and try to develop the right element list for them. After
that I'll try to find out who exactly to implement everything.
Help is welcome.

Jeremias Maerki

Re: Space-resolution doesn't work

[Manuel Mall <mm...@arcus.com.au>]

On Tue, 13 Sep 2005 04:25 pm, Jeremias Maerki wrote:
> FYI, I'm going to try reimplementing the whole space-resolution part
> on the block-progression-dimension (to start with) using the inputs
> from both Luca and Simon and based on my findings I've documented in
> the Wiki:
> http://wiki.apache.org/xmlgraphics-fop/SpaceResolution
>
> I've started by creating a base class "UnresolvedElement" (holding a
> Position instance) from which SpaceElement (holding SpaceProperty)
> and BorderOrPaddingElement (holding a CondLengthProperty) are
> derived. We'll see how well this turns out.
>
Looking forward to seeing the result of this as the same/similar problem 
needs to be solved for the inline-progression-direction.

Side note: The LineLayoutManager currently doesn't add the the 
half-leading trait as space-before/space-after as required by the spec 
(4.5). This means you won't consider these as part of your space 
resolution in bpd although they probably should?

OTOH, I would prefer no big changes to the whole line/inline layout 
stuff until my batch of changes accumulated here are in Subversion.

<snip/>
> Jeremias Maerki

Manuel

Re: Space-resolution doesn't work

[Jeremias Maerki <de...@jeremias-maerki.ch>]

FYI, I'm going to try reimplementing the whole space-resolution part on
the block-progression-dimension (to start with) using the inputs from
both Luca and Simon and based on my findings I've documented in the
Wiki:
http://wiki.apache.org/xmlgraphics-fop/SpaceResolution

I've started by creating a base class "UnresolvedElement" (holding a
Position instance) from which SpaceElement (holding SpaceProperty) and
BorderOrPaddingElement (holding a CondLengthProperty) are derived. We'll
see how well this turns out.

On 09.09.2005 11:07:56 Jeremias Maerki wrote:
> I think we need to revisit the whole space-resolution story. The current
> code is fine for only the simplest of cases. If you look at the 4.3.1
> Space-resolution Rules in the spec the example given there shows quite
> clearly IMO that we probably can't just rely on the right combination of
> Knuth elements to resolved the spaces. Especially rule 3 is quite nasty.
> I'll start from scratch to come up with a better strategy of
> implementing these rules. I'll probably start by documenting a few cases
> in the Wiki and try to develop the right element list for them. After
> that I'll try to find out who exactly to implement everything.
> Help is welcome.
> 
> Jeremias Maerki



Jeremias Maerki