On Fri, 4 Nov 2005 01:11 am, Andreas L Delmelle wrote:
> On Nov 3, 2005, at 10:41, Manuel Mall wrote:
> > <snip />
> > The only limitation I am aware off at the moment is that the
> > "suppress-at-line-break" property is not supported. This is because
> > the
> > char iterator used does only return characters (in the pure Java
> > sense)
> > and not their related XSL-FO properties. At this point in time I
> > consider support for the "suppress-at-line-break" property not as
> > high priority.
> Well, IMO it shouldn't be handled during refinement, exactly because
> the iterators don't have access to the FO's properties. 

Yes there is an argument in favour of dealing with one thing only in one 
place and not like it is currently done doing white-space-treatment 
around hard breaks during refinement and around soft breaks during 
layout. However, it does actually simplify the LMs by removing all 
those unwanted white space (between blocks, at the start of blocks, at 
the end of blocks) early in the process leading to less LMs being 
generated and less conditional logic when they do their processing 
especially knowing that white space removal is a "cross-boundary" 
activity. Therefore IMO it is the right approach.

And regarding the "suppress-at-line-break" property there is no real 
technical issue in exposing it during refinement so the 
white-space-treatment logic can take it into account. It just needs to 
be coded (which is the same as you saying below).

> I know it can 
> be argued that in cases like:
> ...
> <fo:character character="..." suppress-at-line-break="true" />
> </fo:block>
> During refinement, it is already known that the character will be
> suppressed. If the character is whitespace and the iterator is
> modified to deal with that, it will be dropped, regardless of the
> value of suppress-at-line-break (supposing default values for all
> other props).
> But in the most general cases, I think suppress-at-line-break is best
> dealt with during layout, not refinement.
> Then again, modifying the OneCharIterator (or subclassing to
> FOCharIterator?) to correctly deal with fo:characters (removal/
> replacing) is easy enough. So, it's _possible_ to let it access the
> FOs properties. It's only that I'm not sure whether it would be
> _necessary_.
> <snip />
> > As I said above, I believe I got this sorted out. May be I should
> > do an
> > early commit?
> Would be nice. So at least the codebases we're talking about are
> completely in sync.


> Cheers,
> Andreas


Reply via email to