On Wed, 16 Nov 2005 03:45 am, Jeremias Maerki wrote:
> Sounds like a good plan to me. Would you go after that?
I have no problems with the suggestion to move the white space handling 
from Block into its own class so other fo's that need it can make use 
of it.

However, I still need to be convinced that pushing it down to inline 
level is actually of benefit. I am afraid we will end up with the same 
problem we now have at LM level, that is text for a paragraph needs to 
be analysed across fo boundaries and the current LM structures are very 
much in the way of doing that. Whitespace needs to be handled across fo 
boundaries as well. The current iterator structure was designed to 
exactly facilitate that. It seems to be doing it well and I see no 
reason to replace it.

> On 15.11.2005 18:06:13 Andreas L Delmelle wrote:
> > On Nov 15, 2005, at 10:03, Jeremias Maerki wrote:
> >
> > <snip />
> >
> > > The fix is probably to extract handleWhitespace
> > > from Block into a separate class and call it from Block and
> > > Marker.
> >
> > In this respect: I still wonder whether it wouldn't be more
> > convenient to split up the whitespace handling, and deal with the
> > inlines separately. Currently, InlineCharIterator needs to generate
> > boundary characters to indicate start- or end-inline. If we would
> > deal with the whitespace of the inlines at inline-level itself, it
> > should become far more straightforward to apply the 'special' rules
> > (no removal of the first/last space of the inline, or before it).
> >
> > On top of that, it does away with the need to chain together all
> > FOText instances of a whole block (thus making that ugly static
> > 'lastFOTextProcessed' obsolete?)
> >
> > Extracting handleWhitespace() into a separate class would, in any
> > case, be A Good Thing.
> >
> > My 2 cents.
> >
> > Cheers,
> >
> > Andreas
> Jeremias Maerki

Reply via email to